System for card-based service access

ABSTRACT

A service providing apparatus for providing a service to a user of a user interface card ( 10 ) is disclosed. The card ( 10 ) is configured for insertion into a card read device ( 1 ) that has a receptacle ( 4 ) to receive the interface card ( 10 ). The interface card ( 10 ) comprises a substrate ( 12 ) with indicia ( 14 ) formed thereon. The apparatus also comprises a central processing unit for receiving a service identifier and data stored on the card ( 10 ), from the read device ( 1 ). The data is related to a user selected indicia ( 14 ), wherein the central processing unit is configured to provide a service. The service is identified by the service identifier.

This application is a National Stage Filing Under 35 U.S.C. 371 ofInternational Application No. PCT/AU01/01145, filed Sep. 12, 2001, andpublished in English as International Publication No. WO 02/23411 A1, onMar. 21, 2002.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to a control template or smart card foruse with a remote reader device and, in particular, to a card interfacesystem for providing a service. The invention also relates to a computerprogram product including a computer readable medium having recordedthereon a computer program for a card interface system.

BACKGROUND ART

Control pads of various types are known and used across a relativelywide variety of fields. Typically, such pads include one or more keys,buttons or pressure responsive areas which, upon application of suitablepressure by a user, generate a signal which is supplied to associatedcontrol circuitry.

Unfortunately, prior art control pads are somewhat limited, in that theyonly allow for a single arrangement of keys, buttons or pressuresensitive areas. Standard layouts rarely exist in a given field, and soa user is frequently compelled to learn a new layout with each controlpad they use. For example many automatic teller machines (“ATMs”) andelectronic finds transfer at point of sale (“EFTPOS”) devices usedifferent layouts, notwithstanding their relatively similar data entryrequirements. This can be potentially confusing for a user who mustdetermine, for each control pad, the location of buttons required to bedepressed. The problem is exacerbated by the fact that such control padsfrequently offer more options than the user is interested in, or evenable to use.

Overlay templates for computer keyboards and the like are known. Howeverthese are relatively inflexible in terms of design and require a user tocorrectly configure a system with which the keyboard is associated, eachtime the overlay is to be used.

One known system involves a smart card reading device intended for theremote control of equipment. Such, for example, allows a televisionmanufacturer, to manufacture a card and supply same together with aremote control housing and a television receiver. A customer is thenable to utilise the housing, in conjunction with the card, as a remotecontrol device for the television receiver. In this way the televisionmanufacturer or the radio manufacturer need not manufacture a specificremote control device for their product, but can utilise the remotecontrol housing in conjunction with their specific card. However, theabove described concept suffers from the disadvantage in that controldata (e.g. PLAY, RECORD, REWIND commands etc.,) stored upon the card,and to be used for controlling an associated apparatus, comes from themanufacturer of the apparatus and is thus limited in its application.

Another known system involves an operating card reading device known asa ‘remote commander’ used for remote-controlling a video device, audiodevice etc. The operating card of this known system includes a cardidentification mechanism for identifying which mode the remote commanderis operating in and as such what control data is to be transmitted fromthe remote commander. The operating card identification mechanism can bein the form of either electrodes/notches formed on side surfaces of thecards or identification information stored within the operating cards.The operating card identification mechanism can be configured in orderto enable the remote commander to send commands for either a video taperecorder or for a television receiver, depending on the configuration ofthe identification mechanism. Again, this known system suffers from thedisadvantage in that control data (e.g. PLAY, RECORD, REWIND commandsetc.,) to be used for controlling the video tape recorder or television,comes from the manufacturer of the apparatus and is thus limited in itsapplication. Further, the operating card identification mechanism mustbe configured each time the user wishes to change the apparatus to becontrolled and is restricted to the operating card such that theidentification mechanism can not be used to interact with the videodevice, audio device etc., to be controlled.

Still another known smart card system includes optics for receivinginformation from a television channel and a modem for providingreal-time two way communication with an application running on a remoteservice provider. This known smart card system is used for remoteservice transactions such as an existing home shopping application. Inaccordance with this known system, information including home shoppingprogram information, an item name, an item description, an item priceand item commercial and programming re-run times, can be down-loaded toa smart card. The smart card can then use the access information alongwith the modem of the smart card to automatically dial a home shoppingprogram automated service computer to place an order. However, againthis system is limited in its application since the access informationmust be down-loaded to the smart card each time the smart card is to beused to purchase an item and can only be used to purchase the itemspecified by the item name and description.

The above-described systems all lack flexibility and are all limited intheir respective applications. These systems are all used withpre-running applications and there is no interaction with theapplication other than that specified by the manufacturer.

SUMMARY OF THE INVENTION

It is an object of the present invention to substantially overcome, orat least ameliorate, one or more disadvantages of existing arrangements.

According to one aspect of the present invention there is provided aservice providing apparatus for providing a service to a user of a userinterface card, said card being configured for insertion into a cardread device that has a receptacle to receive said interface card, saidinterface card comprising a substrate with indicia formed thereon, saidapparatus comprising:

a central processing unit for receiving a service identifier and datastored on the card, from said read device, said data being related to auser selected indicia, wherein said central processing unit isconfigured to provide a service, said service being identified by theservice identifier.

According to another aspect of the present invention there is provided aservice providing apparatus for providing a service to a user of aninterface card, said card being configured for insertion into a cardread device that has a receptacle to receive said interface card, saidinterface card comprising a substrate with indicia formed thereon, saidapparatus comprising:

means for receiving from the read device a service identifier and datastored within the card, said data being related to a user selectedindicia; and

means for providing a service identified by the service identifier tothe user.

According to still another aspect of the present invention there isprovided a method of providing a service to a user of an interface card,said card being configured for insertion into a card read device thathas a receptacle to receive said interface card, said interface cardcomprising a substrate with indicia formed thereon, said methodcomprising the steps of:

receiving from the read device a service identifier and data storedwithin said card, said data being related to a user selected indicia;and

providing a service identified by the service identifier.

According to still another aspect of the present invention there isprovided a program to be executed by a service providing apparatus forproviding a service to a user of an interface card, said card beingconfigured for insertion into a card read device that has a receptacleto receive said interface card, said interface card comprising asubstrate with indicia formed thereon, said program comprising:

code for receiving from the read device a service identifier and datastored within said card, said data being related to a user selectedindicia; and

code for providing a service identified by the service identifier.

According to still another aspect of the present invention there isprovided a service providing apparatus for use with a read device for acontrol template, said control template having at least one indiciaformed thereon and a memory having data stored therein for controllingequipment, and said card being configured for insertion into said readdevice, said apparatus comprising:

a central processing unit for receiving said data from said read device,said data comprising at least a service identifier and further data,said further data being associated with a user selected indicia, whereinsaid central processing unit is configured to provide a service via saidequipment upon receipt of said further data, said service beingassociated with the service identifier.

According to still another aspect of the present invention there isprovided a set top box for use with a read device for a controltemplate, said control template having at least one indicia formedthereon and a memory having data stored therein for controllingequipment, and said card being configured for insertion into said readdevice, said set top box comprising:

a central processing unit for receiving said data from said read device,said data comprising at least a service identifier and further data,said further data being associated with a user selected indicia, whereinsaid central processing unit is configured to provide a service via saidequipment upon receipt of said further data, said service beingassociated with the service identifier.

According to still another aspect of the present invention there isprovided a computer for use with a read device for a control template,said control template having at least one indicia formed thereon and amemory having data stored therein for controlling equipment, and saidcard being configured for insertion into said read device, said computercomprising:

a central processing unit for receiving said data from said read device,said data comprising at least a service identifier and further data,said further data being associated with a user selected indicia, whereinsaid central processing unit is configured to provide a service via saidequipment upon receipt of said further data, said service beingassociated with the service identifier.

According to still another aspect of the present invention there isprovided a service providing apparatus for providing a service to a carduser that uses a card read device that has a receptacle to receive aninterface card said interface card comprising a substrate and indiciaformed on said substrate, said apparatus comprising:

a central processing unit for receiving from the read device a serviceidentifier and data stored in the card, said data being related to auser selected indicia, said central processing unit also providing tosaid user a service identified by said service identifier according touser pressed indicia.

According to still another aspect of the present invention there isprovided a service providing apparatus for providing a service to a carduser that uses a card read device having a substantially transparenttouch sensitive membrane arranged to overlay a detachable interface cardcomprising a substrate and indicia formed on said substrate, saidapparatus comprising:

a central processing unit for receiving from the read device a serviceidentifier and a user press coordinates pressed on said touch sensitivemembrane and matching the coordinates with data associated with saidindicia to read data matched with said coordinates from said serviceproviding apparatus, said central processing unit also providing to saiduser a service identified by said service identifier according to userpressed indicia.

According to still another aspect of the present invention there isprovided a service providing apparatus for providing a service to a carduser that uses a card read device having a substantially transparenttouch sensitive membrane arranged to overlay a detachable interface cardcomprising a substrate and indicia formed on said substrate, saidapparatus comprising:

a central processing unit for matching the coordinates with dataassociated with said indicia to read data matched with said coordinatesfrom said service providing apparatus in case that said apparatusreceives from the read device a service identifier and a user presscoordinates pressed on said touch sensitive membrane and processing datain case that to that said apparatus receives from the read device dataassociated with said indicia, said central processing unit alsoproviding to said user a service identified by said service identifieraccording to user pressed indicia.

According to still another aspect of the present invention there isprovided a service providing apparatus for providing a service to a carduser that uses a card read device having a substantially transparenttouch sensitive membrane arranged to overlay a detachable interface cardcomprising a substrate and indicia formed on said substrate, saidapparatus comprising:

a central processing unit for receiving a touch coordinates of said userpress on said touch sensitive membrane from read device and moving acursor displayed on a display based on said received coordinates.

According to still another aspect of the present invention there isprovided a service providing apparatus for providing a service to a carduser that uses a card read device having a receptacle to receive aninterface card, said service providing apparatus comprising:

a central processing unit for receiving from said read device a sessionidentifier identifying a current session of a card insertion in saidread device, which is a number that is incremented each time a card isinserted into said read device and determining a validity of saidinserted card by comparing said received session identifier with apreviously received session identifier.

According to still another aspect of the present invention there isprovided a software architecture for a customisable user interfacesystem, said architecture comprising

an interface module for translating user interface signals to a forminterpretable throughout said system;

an event manager operable to receive said interface signals and tocommunicate said signals and further signals between components of saidarchitecture; and

a master launcher for identifying activity of a user interface and forinstigating operation of a launcher module associated with operationsrelated to said user interface, said launcher module managing for saiduser interface the commencement and termination of each of one or moreapplications related to said user interface.

According to still another aspect of the present invention there isprovided a method of launching multiple applications within acustomisable user interface system using a software architecture, saidmethod comprising

translating user interface signals to a form interpretable throughoutsaid system;

receiving said interface signals and communicating said signals andfurther signals between components of said architecture; and

identifying activity of a user interface and instigating operation of alauncher module associated with operations related to said userinterface, said launcher module managing for said user interface thecommencement and termination of each of one or more applications relatedto said user interface.

According to still another aspect of the present invention there isprovided a software architecture for a customisable user interfacesystem, said architecture comprising

an interface module for translating user interface signals to a forminterpretable throughout said system;

an event manager operable to receive said interface signals and tocommunicate said signals and further signals between components of saidarchitecture; and

a master launcher for identifying activity of a user interface and forinstigating operation of a launcher module associated with operationsrelated to said user interface, said launcher module managing for saiduser interface the commencement and termination of each of one or moreapplications related to said user interface, each said application beingaccessible utilising a corresponding service identifier associated withsaid user interface.

According to still another aspect of the present invention there isprovided a program for launching multiple applications within acustomisable user interface system using a software architecture, saidprogram comprising

code for translating user interface signals to a form interpretablethroughout said system;

code for receiving said interface signals and communicating said signalsand further signals between components of said architecture; and

code for identifying activity of a user interface and instigatingoperation of a launcher module associated with operations related tosaid user interface, said launcher module managing for said userinterface the commencement and termination of each of one or moreapplications related to said user interface.

According to still another aspect of the present invention there isprovided a service providing apparatus for providing a service to a carduser, said apparatus being configured for use with a card read devicethat has a receptacle to receive an interface card having icons formedthereon, each of said icons corresponding to event data, said apparatuscomprising:

a central processing unit for receiving said event data related to auser selected icon from said card read device and for executing anapplication corresponding to a service identifier stored within saidinterface card, to provide a service to said user.

According to still another aspect of the present invention there isprovided a method of providing a service to a card user utilising a cardread device that has a receptacle to receive an interface card havingicons formed thereon, each of said icons corresponding to event data,said method comprising the steps of:

receiving said event data related to a user selected icon from said cardread device; and

executing an application corresponding to a service identifier storedwithin said interface card, to provide a service to said user.

According to still another aspect of the present invention there isprovided a program for providing a service to a card user utilising acard read device that has a receptacle to receive an interface cardhaving icons formed thereon, each of said icons corresponding to eventdata, said program comprising:

code for receiving said event data related to a user selected icon fromsaid card read device; and

code for executing an application corresponding to a service identifierstored within said interface card, to provide a service to said user.

According to still another aspect of the present invention there isprovided a service providing apparatus for providing a service to a userof an interface card, said card being configured for insertion into acard read device that has a receptacle to receive said card, saidinterface card comprising a substrate with indicia formed on thereon,said apparatus comprising;

a central processing unit for receiving an identifier and data stored onthe card, from said read device, said data being related to a userselected indicia, and retrieving an application location corresponds tothe received identifier.

According to still another aspect of the present invention there isprovided a program to be executed by a service providing apparatus forproviding a service to a user of an interface card, said card beingconfigured for insertion into a card read device that has a receptacleto receive said card, said interface card comprising a substrate withindicia formed on thereon, said program comprising;

code for receiving from said read device an identifier and data storedon the card, said data being related to a user selected indicia; and

code for retrieving an application location corresponds to the receivedidentifier.

Other aspects of the invention are also disclosed.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments of the present invention will now be describedwith reference to the drawings, in which:

FIG. 1 is a perspective view of a read device and an associated card;

FIG. 2 is a perspective view of an opposite side of the card shown inFIG. 1;

FIG. 3 is a longitudinal cross-sectional view of the card shown in FIG.1 taken along the line III-III;

FIGS. 4 and 5 are perspective views of the rear face of alternativearrangements of cards to the card shown in FIG. 1;

FIG. 6( a) shows a hardware architecture of a card interface system;

FIG. 6( b) shows another hardware architecture of a card interfacesystem;

FIG. 7 is a schematic block diagram of the general-purpose computer ofFIGS. 6( a) and 6(b);

FIG. 8 is a schematic block diagram representation of a card interfacesystem architecture;

FIG. 9 is a schematic block diagram representation of a card interfacesystem;

FIG. 10 is a schematic block diagram showing the internal configurationof the reader of FIG. 1;

FIG. 11 shows the data structure of a card header as stored in the cardof FIG. 1;

FIG. 12 shows a description of each of the fields of the header of FIG.11;

FIG. 13 shows a description of each of the flags contained in the headerof FIG. 11;

FIG. 14 shows a description of each of the fields of the objectstructure for the card of FIG. 1;

FIG. 15 shows a description of the flag for the object structure of FIG.14;

FIG. 16 shows a description of each of the object types for the objectstructure of FIG. 14;

FIG. 17 shows a description of each of the fields for a user InterfaceObject Structure according to the object structure of FIG. 14;

FIG. 18 shows a description for each of the user Interface object flagsaccording to the object structure of FIG. 14;

FIG. 19 shows the format of a message header that is sent from thereader of FIG. 1;

FIG. 20 shows a table listing message event types for the header of FIG.19;

FIG. 21 shows the format of a simple message;

FIG. 21( a) shows the format of an INSERT message;

FIG. 22 shows the format of a MOVE message;

FIG. 23 shows the format of PRESS and RELEASE messages;

FIG. 24 is a data flow diagram showing the flow of messages within thesystem of FIG. 6;

FIG. 25 is a flow diagram showing a read method performed by the readerof FIG. 1;

FIG. 26 is a flow diagram showing a method of initialising the system ofFIG. 6, performed during the method of FIG. 25;

FIG. 27 is a flow diagram showing a method of checking the card of FIG.1, performed during the method of FIG. 25;

FIG. 28 is a flow diagram showing a method of scanning the touch panelof the reader of FIG. 1, performed during the method of FIG. 25;

FIG. 29 is a flow diagram showing a wait 10 ms method, performed duringthe method of FIG. 25;

FIG. 30 is a flow diagram showing an overview of events of the system ofFIG. 6;

FIG. 31 is a flow diagram showing processes performed by the eventmanager during the process of FIG. 30;

FIG. 32 is a flow diagram showing a method for starting a newapplication, performed during the process of FIG. 30;

FIG. 33 is a flow diagram showing a method of ending an applicationperformed during the process of FIG. 30;

FIG. 34 is a flow diagram showing a method of closing a current sessionfor a persistent application;

FIG. 35 is a flow diagram showing a method for performing a focuschange;

FIG. 36 is a flow diagram showing an overview of a method performed bythe launcher;

FIG. 37 is a flow diagram showing a method of changing an application,performed during the method of FIG. 36;

FIG. 38 is a flow diagram showing a method of registering a newapplication, performed during the method of FIG. 36;

FIG. 39 is a flow diagram showing a method performed by an applicationwhen receiving events from the launcher,

FIG. 40 is a flow diagram showing a method performed by the browsercontroller application when receiving events from the launcher,

FIG. 41 is a flow diagram showing a browser application method;

FIG. 42 is schematic block diagram showing the set top box of the system600 in more detail;

FIG. 43 is a perspective view of a “bottom-entry” reader,

FIG. 44 is a plan view of the reader of FIG. 43;

FIG. 45 shows a user inserting a card into the reader of FIG. 43;

FIG. 46 shows a user operating the reader of FIG. 43 after a card hasbeen fully inserted;

FIG. 47( a) is a longitudinal cross-sectional view along the line V-V ofFIG. 44;

FIG. 47( b) is a view similar to FIG. 47( a), with a card partiallyinserted into the receptacle of the reader;

FIG. 47( c) is a view similar to FIG. 47( a), with a card fully insertedinto the template receptacle of the reader.

FIG. 48 is a schematic block diagram representation of a further cardinterface system architecture;

FIG. 49 is a schematic block diagram representation showing therelationships between cards and applications;

FIG. 50 illustrates the relationships between applications and servicegroups;

FIGS. 51A to 51C illustrates different types of card orderings withinthe architecture of FIG. 48;

FIG. 52 illustrates the control template data stored in the smart cardfor the architecture of FIG. 48;

FIGS. 53A to 53E illustrate an example of a multi-card applicationstructure;

FIG. 54 shows an alternative approach to achieve the end of FIGS. 53A to53E;

FIG. 55 shows a directed graph representation of a multi-applicationmethod;

FIG. 56 shows a method of starting an application;

FIG. 57 shows one or more object structures following the card header ofFIG. 11; and

FIG. 58 is a flow diagram, showing an overview of the process performedby the directory service of FIG. 8.

DETAILED DESCRIPTION INCLUDING BEST MODE

Where reference is made in any one or more of the accompanying drawingsto steps and/or features, which have the same reference numerals, thosesteps and/or features have for the purposes of this description the samefunction(s) or operation(s), unless the contrary intention appears.

The embodiments disclosed herein have been developed primarily for usewith remote control systems, automatic tellers, video game controllersand network access, and will be described hereinafter with reference tothese and other applications. However, it will be appreciated that theinvention is not limited to these fields of use.

For ease of explanation the following description has been divided intoSections 1.0 to 13.0, each section having associated subsections.

1.0 Card Interface System Overview

FIG. 1 shows a remote reader 1, having a housing 2, which defines a cardreceptacle 4 and a viewing area 6. Data reading means are provided inthe form of exposed electrical contacts 7 and associated controlcircuitry (not shown). The remote reader 1 also includes sensor means inthe form of a substantially transparent pressure sensitive membraneforming a touch panel 8 covering the viewing area 6. The remote reader 1disclosed herein has been described with a substantially transparentpressure sensitive membrane forming the touch panel 8, however it willbe appreciated by one skilled in the art that alternative technology canbe used as a substantially transparent touch panel. For example, thetouch panel can be resistive or temperature sensitive. The remote reader1 is configured for use with a user interface card, which, in the cardsshown in FIGS. 1 to 3, takes the form of an electronic smart card 10A.The smart card 10A includes a laminar substrate 12 with various controlindicia 14 in the form of a four way directional controller 20, a “jumpbutton” 22, a “kick button” 24, a “start button” and an “end button”printed on an upper face 16 thereof. Other non-control indicia, such aspromotional or instructional material, can be printed alongside thecontrol indicia. For example, advertising material 26 can be printed onthe front face of the smart card 10A or on a reverse face 27 of the card10A, as seen in FIG. 2.

As seen in FIG. 3, the smart card 10A includes storage means in the formof an on-board memory chip 19 for data associated with the controlindicia The smart card 10A also includes electrical data contacts 18connected to the on-board memory chip 19 corresponding with the exposedcontacts 7 on the remote reader 1.

As seen in FIG. 3, the upper face 16 may be formed by an adhesive label60 upon which are printed control indicia 14, in this case correspondingto the “End Button” and the Right arrow “button” of the directionalcontroller 20. The label 60 is affixed to the laminar substrate 12. Ahome user can print a suitable label for use with a particular smartcard 10A by using a printer, such as a colour BUBBLEJET™ printermanufactured by Canon, Inc. Alternatively, the control indicia 14 can beprinted directly onto the laminar substrate or separate adhesive labelscan be used for each of the control indicia.

In use, the smart card 10A is inserted into the card receptacle 4, suchthat the pressure sensitive touch panel 8 covers the upper face 16 ofthe smart card 10A. In this position, the control indicia are visiblewithin the viewing area 6 through the transparent pressure sensitivetouch panel 8.

The exposed contacts 7 and associated circuitry of the reader 1 areconfigured to read the stored data associated with the control indicia14 from the memory chip 19, either automatically upon insertion of thesmart card 10A into the control template receptacle 4, or selectively inresponse to a signal from the remote reader 1. The signal can, forexample, be transmitted to the smart card 10A via the exposed contacts 7and data contacts 18.

Once the data associated with the control indicia 14 has been read, auser can press areas of the pressure sensitive touch panel 8 on or overthe underlying control indicia 14. By sensing the pressure on thepressure sensitive touch panel 8 and referring to the stored data, theremote reader 1 can deduce which of the control indicia 14 the user hasselected. For example, if the user places pressure on the pressuresensitive touch panel 8 adjacent the “kick button” 24, the remote reader1 is configured to assess the position at which the pressure wasapplied, refer to the stored data, and determine that the “kick” button24 was selected. This information can then be used to control anexternal device, for example, an associated video game console (ofconventional construction and not shown). It will be appreciated fromabove that the control indicia 14 are not, in fact buttons. Rather, thecontrol indicia 14 are user selectable features which, by virtue oftheir corresponding association with the mapping data and the functionof the touch panel 8, operate to emulate buttons traditionallyassociated with remote control devices.

In one advantageous implementation, the remote reader 1 includes atransmitter (of conventional type and not shown), such as an infra-red(IR) transmitter or radio frequency (RF) transmitter, for transmittinginformation in relation to indicia selected by the user. As seen in FIG.1, the remote reader 1 incorporates an IR trasmitter having an IR lightemitting diode (LED) 25. Upon selection of one of the control indicia14, the remote reader 1 causes information related to the selection tobe transmitted to a remote console (not shown in FIG.1) where acorresponding IR or RF receiver can detect and decode the informationfor use in controlling some function, such as a game being played by auser of the reader 1.

Any suitable transmission method can be used to communicate informationfrom the remote reader 1 to the remote console, including direct hardwiring. Moreover, the remote console itself can incorporate a trotter,and the remote reader 1 a receiver, for communication in an oppositedirection to that already described. The communication from the remoteconsole to the remote reader 1 can include, for example, handshakingdata, setup information, or any other form of information desired to betransferred from the remote console to the remote reader 1.

Turning to FIG. 4, there is shown a control card 10B. The control card10B includes a laminar substrate 12, which bears control indicia (notillustrated). In the control card 10B the storage means takes the formof a magnetic strip 29 formed along an edge 28 of the reverse face 27 ofthe control card 10B. The stored data associated with the controlindicia may be stored on the magnetic strip 29 in a conventional manner.A corresponding reader (not shown) for this arrangement includes amagnetic read head positioned at or adjacent an entrance to thecorresponding control template receptacle. As the control card 10B isslid into the card receptacle, the stored data is automatically readfrom the magnetic strip 29 by the magnetic read head. The reader 1 maythen be operated in a manner corresponding to the card 10A of FIG. 1.

FIG. 5 shows another card in the form of a control card 10C, in whichthe storage means takes the form of machine-readable indicia In the card10C of FIG. 5, the machine readable indicia takes the form of a barcode36 formed along an edge 38 of the reverse face 27 of the card 10C. Thestored data is suitably encoded, and then printed in the position shown.A corresponding controller (not shown) for the card 10C of FIG. 5includes an optical read head positioned at or adjacent an entrance tothe associated control template receptacle. As the card 10C is slid intothe control receptacle, the stored data is automatically read from thebarcode 36 by the optical read head. Alternatively, the barcode can bescanned using a barcode reader associated with the reader immediatelyprior to inserting the card 10C, or scanned by an internal barcodereader scanner once the card 10C has completely been inserted. The card10C may then be operated in a manner again corresponding to the card 10Aof FIG. 1. It will be appreciated that the position, orientation andencoding of the barcode can be altered to suit a particular application.Moreover, any other form of machine readable indicia can be used,including embossed machine-readable figures, printed alpha-numericcharacters, punched or otherwise formed cut outs, optical or magnetooptical indicia, two dimensional bar codes. Further, the storage meanscan be situated on the same side of the card 10A or 10B or 10C as thecontrol indicia.

FIG. 6( a) shows a hardware architecture of a card interface system600A. In the system 600A, the remote reader 1 is hard wired to apersonal computer system 100 via a communications cable 3.Alternatively, instead of being hardwired, a radio frequency or IRtransceiver 106 can be used to communicate with the remote reader 1. Thepersonal computer system 100 includes a screen 101 and a computer module102. The computer system 100 will be explained in more detail below withreference to FIG. 7. A keyboard 104 and mouse 203 are also provided.

The system 600A includes a smart card 10D which is of similarconfiguration to the smart card 10A described above. The smart card 10Dis programmable and can be created or customised by a third party, whichin this case can be a party other than the manufacturer of the card 10Dand/or card reader 1. The third party can be the ultimate user of thesmart card 10D itself, or may be an intermediary between themanufacturer and user. In accordance with the system 600A of FIG. 6( a),the smart card 10D can be programmed and customised for one touchoperation to communicate with the computer 100 and obtain a service overa network 220, such as the Internet. The computer 100 operates tointerpret signals sent via the communications cable 3 from the remotereader 1, according to a specific protocol which will be described indetail below. The computer 100 performs the selected function accordingto touched control indicia, and can be configured to communicate dataover the network 220. In this manner the computer 100 can permit accessto applications and/or data stored on remote server computers 150, 152and appropriate reproduction on the display device 101.

FIG. 6( b) shows a hardware architecture of a card interface system600B. In the system 600B, the remote reader 1 can be programmed forobtaining a service locally at a set top box 601, that couples to anoutput interface, which in this example takes the form of anaudio-visual output device 116, such as a digital television set. Theset-top box 601 operates to interpret signals 112 received from theremote reader 1, which may be electrical, radio frequency, or infra-red(IR), and according to a specific protocol which will be described indetail below. The set top box 601 can be configured to perform theselected function according to touched control indicia and permitappropriate reproduction on the output device 116. Alternatively, theset top box 601 can be configured to convert the signals 112 to a formsuitable for communication and cause appropriate transmission to thecomputer 100. The computer 100 can then perform the selected functionaccording to the control indicia, and provide data to the set-top box601 to permit appropriate reproduction on the output device 116. The settop box 601 will be explained in more detail below with reference toFIG. 42.

In one application of the system 600B, the smart card 10D can beprogrammed for obtaining a service both remotely and locally. Forinstance, the smart card 10D can be programmed to retrieve anapplication and/or data stored on remote server computers 150, 152, viathe network 220, and to load the application or data on to the set topbox 601. The latter card can be alternatively programmed to obtain aservice from the loaded application on the set top box 601.

Unless referred to specifically, the systems 600A and 600B will behereinafter generically referred to as the system 600. Further, unlessreferred to specifically, the smart cards 10A, 10B, 10C and 10D will behereinafter generically referred to as the smart card 10.

FIG. 7 shows the general-purpose computer system 100 of the system 600,which can be used to run the card interface system and to run softwareapplications for programming the smart card 10. The computer system 100includes a computer module 102, input devices such as a keyboard 104 andmouse 203, output devices including the printer (not shown) and thedisplay device 101. A Modulator-Demodulator (Modem) transceiver device216 is used by the computer module 102 for communicating to and from thecommunications network 220, for example connectable via a telephone line221 or other functional medium. The modem 216 can be used to obtainaccess to the Internet, and other network systems, such as a Local AreaNetwork (LAN) or a Wide Area Network (WAN).

The computer module 102 typically includes at least one centralprocessing unit (CPU) 205, a memory unit 206, for example formed fromsemiconductor random access memory (RAM) and read only memory (ROM),input/output (I/O) interfaces including a video interface 207, and anI/O interface 213 for the keyboard 104 and mouse 203, a write device215, and an interface 208 for the modem 216. A storage device 209 isprovided and typically includes a hard disk drive 210 and a floppy diskdrive 211. A magnetic tape drive (not illustrated) is also able to beused. A CD-ROM drive 212 is typically provided as a non-volatile sourceof data. The components 205 to 213 of the computer module 201, typicallycommunicate via an interconnected bus 204 and in a manner, which resultsin a conventional mode of operation of the computer system 102 known tothose in the relevant art. Examples of computers on which thearrangement described herein can be practised include IBM-computers andcompatibles, Sun Sparcstations or alike computer system evolvedtherefrom.

Typically, the software programs of the system 600 are resident on thehard disk drive 210 and read and controlled in their execution by theCPU 205. Intermediate storage of the software application programs andany data fetched from the network 220 may be accomplished using thesemiconductor memory 206, possibly in concert with the hard disk drive210. In some instances, the application programs can be supplied to theuser encoded on a CD-ROM or floppy disk and read via the correspondingdrive 212 or 211, or alternatively may be read by the user from thenetwork 220 via the modem device 216. Still further, the software canalso be loaded into the computer system 102 from other computer readablemedia including magnetic tape, ROM or integrated circuits, amangeto-optical disk, a computer readable card such as a smart card, acomputer PCMCIA card, and the like. The foregoing is merely exemplary ofrelevant computer readable media. Other computer readable media are ableto be practiced without departing from the scope of the inventiondefined by the appended claims.

The smart card 10 can be programmed by means of a write device 215coupled to the I/O interface 213 of the computer module 102. The writedevice 215 can have the capability of writing data to the memory on thesmart card 10. Preferably, the write device 215 also has the capabilityof printing graphics on the top surface of the smart card 10. The writedevice 215 can also have a function reading data from the memory on thesmart card 10. Initially, the user inserts the smart card 10 into thewrite device 215. The user then enters the required data via thekeyboard 104 of the general purpose computer 102 and a softwareapplication writes this data to the smart card memory via the writedevice 215. If the stored data is encoded for optical decoding such asusing a barcode, the write device can print the encoded data onto thesmart card 10.

FIG. 42 shows the set top box 601 of the system 600, which can be usedto interpret signals 112 received from the remote reader. The set topbox 601 in some implementations essentially is a scaled version of thecomputer module 102. The set top box 601 typically includes at least oneCPU unit 4305, a memory unit 4306, for example formed from semiconductorrandom access memory (RAM) and read only memory (ROM, and input/output(I/O) interfaces including at least an I/O interface 4313 for thedigital television 116, an I/O interface 4315 having an IR transceiver4308 for receiving and transmitting the signals 112, and an interface4317 for coupling to the network 220. The components 4305, 4306, 4313,4315 and 4317 of the set top box 601, typically communicate via aninterconnected bus 4304 and in a manner which results in a conventionalmode of operation. Intermediate storage of any data received from theremote reader 1 or network 220 may be accomplished using thesemiconductor memory 4306. Alternatively, the set top box can include astorage device (not shown) similar to the storage device 209.

The card interface system 600 will now be explained in more detail inthe following paragraphs.

2.0 Card Interface System Software Architecture

2.1 Software Architecture Layout

A software architecture 200 for the hardware architectures depicted bythe system 600, is generally illustrated in FIG. 8. The architecture 200can be divided into several distinct process components and one class ofprocess. The distinct processes include an I/O interface 300, which maybe colloquially called an “I/O daemon” 300, an event manager 301, adisplay manager 306, an (application) launcher 303 and a directoryservice 311. The class of process is formed by one or more applications304. In the architecture 200 described herein, there exists one I/Odaemon 300, one event manager 301, one display manager 306 and onelauncher 303 for every smart card remote connection, usually formed bythe set-top box 601, and one master launcher (not shown) for eachcomputer 100 (e.g. the server computers 150, 152) that is running thelaunchers 303, and at least one directory service 311 for all systems.The Directory service 311, is queried by the launcher 303 to translateservice data into a Resource Locater (eg. URL) that indicates a name orlocation of a service or the location or name of an application 304 tobe used for the service.

In this form, the architecture 200 can be physically separated into sixdistinct parts 101, 307, 309, 312, 313 and 601 as shown by the dashedlines in FIG. 8, each of which can be run on physically separatecomputing devices. Communication between each of the parts of the system600 is performed using Transport Control Protocol/Internet Protocol(TCP/IP) streams. Alternatively, each of the parts 101, 307, 309, 312,313 and 601 can be run on the same machine.

In the system 600A of FIG. 6( a), all of the process components 300,301, 303, 304 and 306 can be run on the computer 100. The event manager301, the launcher 303 and display manager 306 are preferably allintegrated into one executable program which is stored in the hard disk209 of the computer 100 and can be read and controlled in its executionby the CPU 205. The directory service 311 runs on the same computer 100or on a different computer.(e.g. server 150) connected to the computer100 via the network 220.

In the system 600B of FIG. 6( b), all of components 300 to 304 and 306can run from the set-top-box 601. In this instance, the components 300to 304 and 306 can be stored in the memory 4306 of the set top box 601and can be read and controlled in their execution by the CPU 4305. Thedirectory service 311 can run on the computer 100 and can be stored inthe memory 206 of the computer 100 and be read and controlled in itsexecution by the CPU 205. Alternatively, the directory service 311 canbe run on the set top box 601 or its function performed by the launcher303.

Alternatively, if the set-top-box 601 is not powerful enough to run thesystem 600 locally, only the I/O daemon 300 need run on the set-top-box601 and the remainder of the architecture 200 (i.e. process components301, 303, 304, 306 and 311) can run remotely on the other servers (150,152) which can be accessed via the network 220. In this instance, theI/O daemon 300 can be stored in the memory 4306 of the set top box 601and can be read and controlled in its execution by the CPU 4305. Again,the functional parts of such a system can be divided as shown in FIG. 8.

2.1.1 I/O Daemon

The I/O daemon 300 is a process component that converts datagramsreceived from the remote reader 1 into a TCP/IP stream that can be sentto the event manager 301 and vice versa (e.g. when using a two-wayprotocol). Any suitable data format can used by the remote reader 1. TheI/O daemon 300 is preferably independent of any changes to the remotereader 1 data format, and can work with multiple arrangements of theremote reader 1. In one advantageous implementation of the system 600,the I/O daemon 300 is integrated into the event manager 301.

In the system 600A, the I/O daemon 300 is started when a user starts thesmart card system 600 by powering up the computer 100 and the eventmanager 301 has been started. Alternatively, the I/O daemon 300 isstarted when a user starts the system 600 by turning on the set-top box601.

The I/O daemon 300 will be explained in more detail below with referenceto section 9.0.

2.1.2 Event Manager

The event manager 301 forms a central part of the architecture 200 inthat all communications are routed through the event manager 301. Theevent manager 301 is configured to gather all events that are generatedby the remote reader 1 and relayed by the I/O daemon 300. These eventsare then redistributed to the various process components 300 to 304, and306 and running applications. The event manager 301 is also configuredto check that an event has a valid header, correct data length, but istypically not configured to check that an event is in the correctformat. An “event” in this regard represents a single data transactionfrom the I/O daemon 300 or the launcher 303 or applications 304.

Any changes in protocol between different systems can be dealt with bythe event manager 301. Where possible, events can be rewritten toconform to the data format understood by any presently runningapplication 304. If such is not possible, then the event manager 301reports an error to the originating application 304. When different dataformats are being used, for example with a system running multiple smartcards, the event manager 301 preferably ensures that the smallestdisruption possible occurs.

The event manager 301 does not have any presence on the display screenor other output device 116. However, the event manager 301 can beconfigured to instruct the display manager 306 as to which applicationis presently required (i.e. the “front” application) and shouldcurrently be displayed on the display 101. The event manager 301 infersthis information from messages passed to the applications 304 from thelauncher 303 as will be explained in more detail below with reference tosection 10.0.

The event manager 301 can be configured to always listen for incomingI/O daemon connections or alternatively, can start the system 600. Themethod used is dependent on the overall configuration of the system 600.In this connection, the event manager 301 can start the system 600 orthe set top box 601 can use the incoming connection of the I/O daemon300 to start the system 600. The event manager 301 will be described inmore detail below with reference to section 7.0.

2.1.3 Master Launcher

Where a thin client computer is being utilised and multiple launchers303 are running with each launcher 303 being responsible for one set topbox, a master launcher (not shown) which communicates directly with theevent manager 301 can be used. The master launcher is used to start thelauncher 303 corresponding to each of the event managers 301 if morethan one event manager is running on the system 600. Initially, when theI/O daemon 300 connects to the event manager 301, the event manager 301requests that the master launcher start a first process for the eventmanager 301. This first process is generally the launcher 303 for anysmart card application 304. The master launcher can also be configuredto shut down the launcher 303 of an application 304 when the eventmanager 301 so requests, and for informing the event manager 301 thatthe launcher 303 has exited.

There is preferably one master launcher running for each physicallyseparate server (e.g. 150, 152) that is running an associated smart cardapplication 304. This one master launcher handles the requests for allevent managers that request launchers on a particular server. When runon a computer 100, as seen in FIG. 7, the master launcher commencesoperation either before or no later than at the same time as the rest ofthe system 600. In this instance, the master launcher is started first.

The master launcher can be integrated into the event manager 301, forexample, when an associated launcher is running on the same computer asthe event manager 301.

2.1.4 Launcher/First Application

In one advantageous implementation of the system 600, the first processstarted by the insertion of a smart card 10 into the remote reader 1 isthe launcher 303. In specific systems, specific applications may becommenced, for example an automatic teller machine can start a bankingapplication. Another example includes the use of restricted launchersthat only start a specified sub-set of applications. The launcher 303 isan application that starts other applications for a specific eventmanager 301. The launcher 303 starts and ends applications and can alsostart and end sessions. The launcher 303 also informs the event manager301 when applications are starting and ending, and tells theapplications 304 when they are receiving or losing focus, or when theyneed to exit. In this regard, where a number of applications 304 areoperating simultaneously, the application 304 that is currentlyon-screen is the application having focus, also known as the “frontapplication”. When another application is about to take precedence, thelauncher 303 tells the front application that it is losing focus,thereby enabling the current application to complete its immediatetasks. The launcher 303 also tells the new application 304 that it isgaining focus, and that the new application 304 shall soon be changingstate. The launcher 303 is also configured to force an application toexit.

The launcher 303 may receive certain events such as “no-card”, “lowbattery” and “bad card” events generated by the remote reader 1. Thelauncher 303 also receives events that are intended for applicationsthat are not currently the front application, and the launcher 303operates to correctly interpret these events.

The launcher 303 is preferably only started when a request is generatedby the event manager 301 to request the launcher 303 to be started. Thelauncher 303 can also be told to exit and forced to exit by the eventmanager 301.

The launcher 303 is preferably the only process component that needs tocommunicate with the directory service 311. When the launcher 303 isrequired to start a new application 304, the launcher 303 queries thedirectory service 311 with service data, and the directory service 311returns a location of the application 304 and service data associatedwith the new application 304. The service data is sent to the newapplication 304 as initialisation data in an event, referred to hereinas the EM_GAINING_FOCUS event. The application location specifies thelocation of the application 304 to be run. This may be local, forimplementations with a local computer, or networked. If the applicationlocation is empty, then the launcher 303 has to decide which applicationto start based on the service data.

The launcher 303 can also be configured to start any applications, forexample browser controllers that will generally always be running whilethe system 600 is operating. Such applications are referred to aspersistent applications. Applications can also be started by thelauncher 303 either as a response to the first user selection on acorresponding smart card 10, or at the request of another one of theapplications 304.

The launcher 303 can be integrated into the event manager 301 in someimplementations of the system 600.

The launcher 303 will be explained in more detail below with referenceto section 10.0.

2.1.5 Display Manager

The display manager 306 selects which smart card application 304 iscurrently able to display output on the display screen 101. The displaymanager 306 is told which application 304 can be displayed by anEM_GAINING_FOCUS event originating from the launcher 303. This event canbe sent to the display manager 306 directly, or the event manager 301can send copies of the event to the display manager 306 and the intendedrecipient.

Generally, the only application 304 that should be attempting to displayoutput should be the front application. The display manager 306 canprovide consistent output during the transfer between applicationshaving control of the display. The display manager 306 may need to useextrapolated data during changeovers of applications as the frontapplication.

The architecture 200 can be configured such that the display manager 306is not needed or the role of the display manager 306 may be assumed bythe other parts 301 or 303, of the architecture 200.

2.1.6 Directory Service

The directory service 311 is configured to translate service identifiersthat are stored on smart cards 10, into resource locators (e.g. a URL)that indicate the location of the services or the location of anapplication associated with a service. The directory service 311 is alsoconfigured to translate optional service data. The directory service 311allows the launcher 303 associated with a particular card 10 to decidewhat to do with a resource locator, for example, download and run theassociated application 304 or load the resource locator into a browserapplication. The translation by the directory service can be performedusing a distributed lookup system.

2.1.7 Applications

The applications 304 associated with a particular smart card 10 can bestarted by the launcher 303 associated with that smart card 10 in aresponse to a first button press on a corresponding card. Eachapplication 304 can be a member of one or more service groups, describedin detail later in this specification. An application 304 can bespecified to not be part of any service group in which case theapplication will never be run with other applications. An applicationcan become part of a service group once the application is running andcan remove itself from a service group when the application is thecurrently front application.

Some applications can be started when the system 600 is started andthese applications, for example a browser control application or a mediaplaying application can be always running. These persistent applicationscan be system specific or more generally applicable.

FIG. 9 is a schematic block diagram representation of a card interfacesystem, including the process components 301 to 306 described above. Inthe system of FIG. 9, the remote reader 1 communicates with a computer100 via an IR link in conjunction with an I/O daemon 300 for controllingthe IR link. Further, the computer 100 is configured for communicatingto and from a communications network in this case represented by theInternet 400 to a Web server 410. In this instance, some of theapplications 304 accessible utilising the smart cards 10 and remotereader 1 can be Web pages 406 associated with different smart cards 10.The Web libraries 407 contain functions (e.g. JavaScript functions) andclasses (e.g. Java classes) that can be included with web pages for usewith the smart card 10. The Web pages 406 can be accessed with a runningapplication called the Web browser 403. In the system of FIG. 9, theevent manager 301 is configured to receive an event from the remotereader 1. The event is then sent to the launcher 303, which can beconfigured to send a message to the browser controller 402, whichcontrols the Web browser 403. The process for starting an application orbrowser session will be explained in more detail below. The launcher 303can also be configured to download applications 408 as well as runningapplications from a file server 411 which is also connected to thecomputer 100 via the Internet 400.

3.0 Reader

The remote reader 1 is preferably a hand-held, battery-powered unit thatinterfaces with a smart card 10 to provide a customisable userinterface. As described above, the remote reader 1 is intended for usewith a digital television, a set top box, computer, or cable televisionequipment to provide a simple, intuitive interface to on-line consumerservices in the home environment.

FIGS. 43 and 44 show a reader 4401 similar to the reader 1 describedabove. The reader 4401 is configured for the reading of the card 10. Thereader 4401 is formed of a housing 4402 incorporating a card receptacle4404 and a viewing area 4406. The receptacle 4404 includes an accessopening 4410 through which a smart card 10, seen in FIG. 1, isinsertable.

An upper boundary of the viewing area 4406 is defined by sensor means inthe form of a substantially transparent pressure sensitive membrane 4408similar to the membrane 8 described above. Arranged beneath the membrane4408 is data reading means provided in the form of an arrangement ofexposed electrical contacts 4407 configured to contact complementarycontacts of the smart card 10.

The card 10 is inserted into the reader 4401 via the access opening 4410as shown in FIG. 45. The configuration of the reader 4401 allows a userto hold the reader 4401 in one hand and easily insert the smart card 10into the reader 4401 with the user's other hand. When the smart card 10is fully inserted into the reader 4401, the pressure sensitive membrane4408 fully covers the upper face 16 of the smart card 10. The viewingarea 4406 preferably has substantially the same dimensions as the upperface 16 of the card 10 such that the upper face 16 is, for all intentsand purposes, fully visible within the viewing area 4406 through thetransparent pressure sensitive membrane 4408.

FIG. 46 shows a user operating the reader 4401 after a card has beenfully inserted.

Referring to FIGS. 47( a) to 47(c), the housing 4402 is formed of asubstantially two part outer shell defined by a top section 4827 thatsurrounds the membrane 4408, and a base section 4805 which extends froma connection 4829 with the top section 4827 to a location 4811 below andproximate the transverse centre of the membrane 4408. The base section4805 incorporates a facing end 4815 formed from infrared (IR)transparent material thereby permitting IR communications being emittedby the reader 4401.

The location 4811 defines a point of connection between the base section4805 a card support surface 4807 which extends through a plane in whichthe contacts 4407 lie to an interior join 4835 that sandwiches themembrane 4408 between the surface 4807 and the top section 4827. Theaccess opening 4410 is substantially defined by the space between thelocation 4811 and a periphery 4836 of the housing 4402, seen in FIG. 47(a).

The contacts 4407 extend from a connector block 4837 mounted upon aprinted circuit board (PCB) 4801, the PCB 4801 being positioned betweenthe base section 4805 and the support surface 4807 by way of the twomountings 4817 and 4819. Arranged on an opposite side of the PCB 4801 tothe connector block 4837 is electronic circuitry (not shown),electrically connected to the connectors 4407 and the touch sensitivemembrane 4408 and configured for reading data from the card 10 accordingto depression of the membrane 4408. Also mounted from the PCB 4801 is aninfrared light emitting diode (LED) 4800 positioned adjacent the end4815 which acts as an IR window for communications with a device (e.g.the set top box 601) to be controlled.

FIG. 47( b) shows a similar view to FIG. 47( a), with the smart card 10partially inserted through the access opening 4410 into the receptacle4404. As can be seen in FIG. 47( b), the support surface 4807 has anintegrally formed curve contour 4840 that leads downward from the planeof the contacts 4407 towards the join 4811. This configuration allowsthe reader 4401 to receive the smart card 10 such that the smart card 10may be initially angled to the plane of the receptacle 4404, as seen inFIG. 47( b). The configuration of the curve contour portion 4840 of thesupport surface 4807 guides the smart card 10 into a fully insertedposition under the force of the user's hand. Specifically, as the card10 is further inserted, the curvature of the support surface 4807 guidesthe card 10 into the plane of the contacts 4407 and receptacle 4404.

FIG. 47( c) shows a similar view to FIG. 47( a), with the smart card 10fully inserted into the receptacle 4404. In this position, the card 10lies in the plane of the receptacle 4404 and the contacts 4407 whichtouch an associated one of the data contacts (not seen) of the smartcard 10, and the smart card 10 is covered by the pressure sensitivemembrane 4408. Further, the contacts 4407 are preferably spring contactsthat act to provide a force against the card 10 and associated with themembrane 4408, sufficient for the card 10 to be held within thereceptacle by a neat interference fit.

In the following description references to the reader 1 can be construedas references to a reader implemented as the reader 1 of FIG. 1 or thereader 4401 of FIGS. 43 to 47( c).

FIG. 10 is a schematic block diagram showing the internal configurationof the remote reader 1 in more detail. The remote reader 1 includes amicrocontroller 44 for controlling the remote reader 1, coordinatingcommunications between the remote reader 1 and a set top box 601, forexample, and for storing mapping information. The microcontroller 44includes random access memory (RAM) 47 and flash (ROM) memory 46. Themicrocontroller 44 also includes a central processing unit (CPU) 45. Themicrocontroller 44 is connected to a clock source 48 and a clockcontroller 43 for coordinating the timing of events within themicrocontroller 44. The CPU 45 is supplied with electrical power from a5 volt battery 53, the operation of the former being controlled by apower controller 50. The microcontroller 44 is also connected to abeeper 51 for giving audible feedback about card entry status and for“button” presses.

Infra-red (IR) communications are preferably implemented using twocircuits connected to the microcontroller 44, an IR transmitter(transmitter) 49 for IR transmission and an IR receiver (receiver) 40for IR reception.

The pressure sensitive touch panel 8 of the remote reader 1 communicateswith the microcontroller 44 via a touch panel interface 41. A smart cardinterface 42 connects to the electrical contacts 7.

An in-system programming interface 52 is also connected to themicrocontroller 44, to enable programming of the microcontroller 44 byway of the microcontroller FLASH memory 46 with firmware. The firmwarewill be explained in further detail later in this document withreference to section 6.0.

The internal configuration of the remote reader 1 will now be describedin further detail.

3.1 Low Power Mode Lifetime

The power controller 50 is operable to provide two power modes, onebeing a low-power “sleep” mode, and another being an active mode. Thelow power mode lifetime is the lifetime of the battery 53 expressed inyears. When the remote reader 1 is not functioning and is in the lowpower mode, the lifetime can be between greater than 2 years.

If the reader 1 is in sleep mode and a user presses the touch panel 8,the remote reader 1 then comes out of sleep mode, and the CPU 45calculates the touch co-ordinates and sends a serial message byinfra-red transmission. The battery 53 should preferably remainserviceable for the current supply requirements of more than 100,000button presses.

3.2 Service Life

The service life is defined as the period of time that the remote reader1 can be expected to remain serviceable, not including batteryreplacement. The service life is related to the Mean Time BetweenFailures (MTBF) figure and is usually derived statistically usingaccelerated life testing. The service life of the remote reader 1 canthus be greater than 5 years.

3.3 Microcontroller

The microcontroller 44 of the remote reader 1 has an 8 bit central CPUwith 4096 bytes of FLASH memory 46 and 128 bytes of random access memory47. The microcontroller 44 preferably operates on a supply voltage from3 to 5 Volts and has flexible on-board timers, interrupt sources, 8 bitanalog to digital converters (ADC), clock watchdog and low voltage resetcircuits. Preferably, the microcontroller 44 also has high currentoutput pins and can be programmed in circuit with only a few externalconnections.

3.4 Clock Source

The main clock source 48 for the remote reader 1 is preferably a 3 pin4.91 MHz ceramic resonator with integral balance capacitors. Thefrequency tolerance is 0.3%. While such tolerance is not as good as acrystal, such is however adequate for serial communications and is muchsmaller and cheaper than a crystal.

3.5 Beeper

The beeper 51 is included with the remote reader 1 to give audiblefeedback about card entry status and for button presses. The beeper 51is preferably a piezo-ceramic disk type.

3.6 Infra-red Communications

As described above, infra-red (IR) communications are preferablyimplemented using two circuits, an IR transmitter 49 for IR transmissionand an IR receiver 40 for IR reception. The two circuits 40 and 49 arepreferably combined on a printed circuit board (e.g the PCB 4801 of FIG.47) within the remote reader 1. The printed circuit board 4801 can beconnected to the microcontroller 44 by a 4 way flat printed cable. Largebulk decoupling capacitors (not shown) are required on the PCB 4801 toprovide surge currents, which are required when transmitting.

3.7.1 Infra-red Transmission

IR transmission is preferably by means of an infra-red Light EmittingDiode (LED) (e.g. the LED 4800 of FIG. 47( a)) forming part of the IRtransmitter 49.

3.7.2 Infra-red Reception

The IR receiver 40 is preferably integrated with an infra-red filter, aPIN diode, an amplifier and discriminator circuitry into a singledevice. Received serial information passes directly from this device toan input port of the microcontroller 44. This port can be programmed togenerate an interrupt on receiving data allowing speedy storage andprocessing of incoming signals.

3.8 CPU/Memory Card Interface

The remote reader 1 can preferably support smart cards 10 as defined bythe International Standards Organisation (ISO) standards 7816-3 and ISO7810. Three and five volt CPU cards (i.e. cards with an embeddedmicroprocessor) with T=0 and T=1 protocols can also be supported as are3 and 5V memory cards.

The electrical contacts 7 used to make contact between the card 10 andthe microcontroller 44 are preferably a surface mount connector with 8sliding contacts and a “card in” switch. In accordance with the ISOrequirements the following signals must be provided:

-   -   Pin 1—VCC—Supply voltage;    -   Pin 2—RST—Reset signal. Binary output to card;    -   Pin 3—CLK—Clock signal, Binary output to card;    -   Pin 4—RFU—Reserved, leave unconnected;    -   Pin 5—GND—Ground;    -   Pin 6—VPP—Programming voltage, not required, link to GND, VCC or        open;    -   Pin 7—I/O—Data I/O, bi-directional signal; and    -   Pin 8—RFU—Reserved, leave unconnected.

The RST and I/O pins are preferably connected directly to themicrocontroller 44. All pins except the power supplies are equipped withseries termination and transient voltage suppressor diodes to preventelectrostatic discharge problems.

3.9 CPU Card Power Supply

As described above, the microcontroller 44 requires a 3-5 Volt powersupply for operation. The 5 Volt supply can be generated from a 3VLithium coin cell operating as the battery 53 by means of the powercontroller 50 in the form of a regulated 5V charge-pump DC-DC converterchip.

3.10 Touch Sensitive Interface

As described above, the pressure sensitive touch panel 8 of the remotereader 1 communicates with the microcontroller 44 via a touch panelinterface 41. The touch panel interface 41 provides an analog signalaccording to the position of the touch on the touch panel 8. This analogsignal is then communicated to the microcontroller 44.

The calculation of touch co-ordinates requires bottom and left touchpanel 8 contacts (not shown) to be connected to the inputs of an analogto digital converter on the microcontroller 44.

A touch on the touch panel 8 can preferably be used to wake up theremote reader 1 from sleep mode. A resistive connection from the leftscreen contact to a sleep WAKE UP port as illustrated provides thisfeature. Note that during in-system programming, up to 8 volts may beapplied to a pin on the microcontroller 44 referred to as the InterruptRequest Pin (IRQ) so a clamping diode needs to be fitted to this pin toprevent device damage. In this instance, it is the internal pull up onthe IRQ pin that actually provides the bias required to detect touchpanel 8 presses.

3.11 Battery

As described above, the remote reader 1 uses a battery 53. A 5 Voltlithium coin cell can be used as the battery 53 to power all thecircuitry of the remote reader 1.

3.12 In System Programming

The microcontroller supports in-system programming (ISP) options. Thein-system programming interface 52 is used in the remote reader 1 toperform programming of the microcontroller 44 such as programming of themicrocontroller FLASH ROM memory 46 with firmware.

3.13 Printed Circuit Boards and Interconnection

The remote reader 1 can include two printed circuit boards (PCB),instead of the one PCB 4801 of the reader 4401, as follows:

-   (i) an infra-red (IR) PCB which holds the infra-red diode, drive FET    and receiver, and-   (ii) a main PCB (e.g. the PCB 4801 of FIG. 47( a)) which holds all    the other components 40 to 53 mentioned above.

Both of the PCB boards described above are preferably double sideddesigns using standard grade FR4, 1.6 mm PCB material. The main PCBpreferably utilises surface mount components since the thickness of thefinished PCB is critical and preferably components are restricted to aheight of approximately 3 mm max.

The IR PCB can use through hole parts but again there are preferablystringent component height restrictions imposed. The interconnection ofthe two PCBs is via a custom designed 4 way flat printed cable (FCA).This interfaces to the two PCBs via a surface mount FCA connector thatis the same part used to interface to the touch panel 8.

3.14 Low Power Mode

When the remote reader 1 has not been used for a short period of time,pre-programmed firmware preferably puts the unit into the low-power modeto conserve battery life. In low-power mode, the supply voltage isswitched off to all current consuming components, the ports of themicrocontroller 44 are set into a safe sleep state and the clock 48 isstopped. In this state the current consumption of the remote reader 1 isless than 5 μA. A P-channel FET can be used to control the supply ofpower to the current consuming components.

There are three alternative preferred methods to wake the remote reader1 up from low power mode as follows:

-   -   touch the touch panel 8;    -   insert a card into the card receptacle 4; and    -   remove and re-insert the battery 53.

The card insert wake up enables the remote reader 1 to always beep whena card is inserted, regardless of whether the unit is in low power modeor not. The touch and card insert wake ups are handled by the IRQ pin asillustrated on the microcontroller 44. It is important that this pin isset to “edge trigger” only so that only a new touch or card insert wakesthe microcontroller up. If IRQ sensitivity is set to “level” triggerthen inadvertently leaving the touch panel 8 pressed, for example whenthe remote reader 1 is packed in luggage, would prevent the remotereader 1 from entering low power mode.

3.15 Interrupts and Resets

The microcontroller 44 firmware for the remote reader 1 uses twoexternal and one internal interrupt sources. External interrupts comefrom the IRQ pin for low power mode wake up. The internal interrupt istriggered by a timer overflow and is used to time various externalinterfaces. These interrupts are serviced by pre-programmed firmwareprocedures.

There are four possible reset sources for the microcontroller asfollows:

-   -   low supply voltage reset at 2.4 Volts;    -   illegal firmware op-code reset;    -   Computer Operating Properly (COP) reset if firmware gets stuck        in a loop; and    -   ISP reset forced onto a RESET pin when in-system programming        (ISP) starts.        4.0 Card Data Format

The format of data for the card 10 described above will be described inthe following paragraphs. For memory cards such as the control card 10Bas described in relation to FIG. 4, data conforming to the format to bedescribed will be copied directly onto the card. For the CPU cardsdescribed above, data conforming to the format to be described can beloaded as a file into the file system of the CPU of the card.

The card 10 described above preferably stores a data structure thatdescribes various card properties and any user-interface indicia printedon the card. The cards 10 can also include global properties thatspecify attributes such as information about the card, vendor and aservice. User-interface objects, if present, specify data to associatewith areas of the surface of the card 10.

The user-interface objects as described herein, represent mapping data,which relate predetermined areas, or iconic representations directlyimprinted on a surface of the card 10, to commands or addresses (eg:Uniform Resource Locators (URLs)). The mapping data includes coordinateswhich typically define the size and location of user Interface Elements(eg: predetermined areas) on the card 10. In this connection, the termuser interface element typically refers to indicia on the card 10,whilst the term user interface object typically refers to the datarelated to a particular indicia. However, these terms are usedinterchangeably throughout the following description.

The user-interface objects are preferably stored directly on the card10. Alternatively, the user-interface objects can be stored not on thecard 10 itself, but in the system 600. For example, the card 10 canstore, via an on-card memory, a barcode or a magnetic strip, a uniqueidentifier, which is unique to cards 10 having substantially similaruser interface elements and layout. The unique identifier together withthe coordinates determined from the touch- panel 8, as a result of auser press, can be transmitted by the reader 1 to the computer 100 or tothe set top box 601, of the system 600. The system 600 having theuser-interface objects stored on the computer 100, set top box 601 or aserver 150, can perform the mapping from the determined coordinates to acorresponding command, address or data relevant to a service associatedwith the card 10 and the user press, in order to provide a desiredfunction represented by the user interface element on the card 10. Inthis instance, the data related to the user selected indicia asdescribed above takes the form of coordinates determined by the reader 1as a result of a user press on a portion of the touch panel 8 whichoverlays the desired indicia

In the cards (e.g. 10) described above, data stored by the card 10includes a card header followed by zero or more objects as described inthe following sections.

4.1 Card Header

FIG. 11 shows the data structure of a card header 1100 as stored in thesmart card 10. The header 1100 includes a number of rows 1101, each ofwhich represent four bytes of data. The data is preferably in ‘bigendian’ format. The complete header is 20 bytes long and includes thefollowing fields (described in more detail in FIG. 12):

-   (i) magic number field 1102, which includes a constant specifying a    card as being a valid memory card. For example, the magic number    field 1102 can be used to check or verify that a propriety card    belonging to a particular manufacture is being used.-   (ii) versions field 1103, which includes each version increment that    specifies a change in the card layout that can not be read by a    reader which is compatible with lower versions of the layout;-   (iii) reserved field 1104, this field is reserved for future use;-   (iv) flags field 1105, which includes flags for a card (see FIG.    13);-   (v) distinguishing identifier field 1110, which includes two    fields—a service 1106 and a service specific field 1107. The service    field 1106 identifies the service of a corresponding card and the    service specific field 1107 optionally contains a service-specific    value;-   (vi) a number of objects field 1108, which includes a number value    representing how many objects follow the header. This field can be    set to zero; and-   (vii) a checksum field 1109, which includes a card checksum of all    data on the card excluding the checksum itself.    FIG. 12 provides a description of the content of the various    (number) fields described with reference to FIG. 11. In particular,    the distinguishing ID number field 1110 comprises an eight byte    distinguishing identifier. The distinguishing identifier includes    two portions, unit pieces of data, namely, a service identifier and    a service-specific identifier. Preferably, the distinguishing    identifier is arranged so that the service identifier occupies five    bytes and the service-specific identifier occupies three bytes of    the total distinguishing identifier value.

The service identifier contained in the field 1106 distinguishes oneservice from another or distinguishes one vendor from another. That is,for example, a service can be associated with an application thatprovides the service to a card user as distinct from a vendor who canprovide multiple services to the card user by providing multipleapplications.

The service identifier can be an identifier to identify the applicationto be used or application location (e.g. URL). Also, generic cards maybe added to the System 600A or 600B and they are a special use of theService identifier. The Generic cards are cards with a special Serviceidentifier that can be used to provide input to a current applicationalready running. The special value for the service 0x0000000001 is knownas “the generic service identifier” and is used on “generic cards”. Ageneric card can be used to send data to the front application alreadyrunning. These are used, for example, for keypads that can be used tosend text input to any application or a card with personal details thatalso may be used to submit this information to any application.

The service—specific identifier contained in the field 1107 can beoptionally used by the vendor of a particular service to providepredetermined functions associated with that particular service. The useof the service-specific identifier is substantially dependent upon theapplication 304 run on the system 600. For example, the serviceidentifier together with the service-specific identifier can be used asa unique identifier for a card 10. This unique identifier can be used togain or deny access to a specific feature associated with a particularservice, to reproduce a specific-service identifier in a log file inorder to confirm or verify that a particular card 10 having that valuewas used to access a service, and to provide a unique identifier thatcan be matched up with a corresponding value in a database in order toretrieve information about the user of the service (eg: name, address,credit card number etc).

Another example of a use for the service-specific identifier can includeproviding information about a mechanism or mode of distribution of thecards 10 (e.g. by mail, bus terminal kiosks, handed out on a train etc).Further, the service-specific identifier, can identify what data shouldbe loaded into the system 600 when a service is accessed.

The foregoing is not intended to be an exhaustive list of possible usesor applications of the service-specific identifier but a small sample ofpossible applications and there are many other applications of theservice-specific identifier of field 1107.

4.1.1 Card Flags

The flags field 1105 of the header 1100 of FIG. 11 may include threeflags as follows:

(i) Don't beep;

(ii) No move events; and

(iii) No event co-ordinates.

FIG. 13 shows a description of each of the above flags. The above flagsaffect the functions that a smart card 10 can perform in a remote reader1, as is defined by the description of each flag. An example, of a userinterface element as referred to in FIG. 13 is a “button” on the card10. user interface elements will be explained in further detail later inthis document.

4.2 Objects

As shown in FIG. 57, immediately following the card header 1100 of FIG.11 can be zero or more object structures 5713 defining the objects of aparticular card 10 and forming part of the data stored on the card 10.Each object structure 5713 comprises four fields as follows:

-   (i) a type field 5701;-   (ii) an object flags field 5703;-   (iii) a length field 5705; and-   (iv) a data field 5707.

The structure of the data field 5707 depends on the object type as willbe described below.

FIG. 14 shows a description of each of the fields 5701, 5703, 5705 and5707 of the object structure 5713. The flags field 5703 of the objectstructure 5713, preferably includes an inactive flag. FIG. 15 shows adescription of the inactive flag.

There are preferably five object types provided for the cards 10A, 10B,10C and 10D described above, as follows:

(i) user Interface objects (i.e. data defining a button on the card 10);

(ii) Card Data;

(iii) Fixed Length Data;

(iv) Reader Insert;

(v) No operation; and

(vi) No operation (single byte).

FIG. 16 shows a description of each of the above object types (i) to(vi).

4.2.1 User Interface Object

Each user interface object defines a rectangular area on the card 10 andsome quantity of associated data that is transmitted when the usertouches an area of the panel 8 over the corresponding rectangular areaof the card 10. The origin for the co-ordinate mapping system is the topleft of the smart card 10 as if it was an ISO standard memory smart cardheld in a portrait view with the chip contacts 18 facing away from theviewer and towards the bottom of the card 10. For any reader 1 that doesnot use this card orientation, the values of the corner points must beadjusted by the reader 1 so as to report a correct “button” press.

The user interface (element) object structure preferably has six fieldsas follows:

-   (i) a flags field;-   (ii) an X1 field;-   (iii) an Y1 field;-   (iv) an X2 field;-   (v) a Y2 field; and-   (vi) a data field which typically includes data associated with the    user interface element for example, a URL, a command, a character or    name.

FIG. 17 shows a description of each of the above fields for thedescribed user interface object structure. A press on the pressuresensitive touch panel 8 is defined to be inside a particular userinterface object if:

-   -   (i) the X value of the press location is greater than or equal        to the X1 value of the associated user interface object and is        strictly less than the X2 value for that particular user        interface object; and    -   (ii) the press Y value for the press location is greater than or        equal to the Y1 value of the particular user interface element        and strictly less than the Y2 value.

Overlapping user interface elements is allowed. If a press is within thebounds of more than one user interface element then the object sent isdetermined by a Z order. The order of the user interface elements on thecard defines the Z ordering for all of the user interface elements onthat particular card The top user interface element is the first userinterface element for a particular card 10. The bottom user interfaceelement is the last user interface element for that particular card 10.This allows for non-rectangular areas to be defined. For example, todefine an “L” shaped user interface element, a first user interfaceobject would be defined with zero bytes in the data field, and a seconduser interface object would be defined to the left and below the firstuser interface object but overlapping the user interface object.

The location of a press is to be reported in “fingers”, which representfinger elements (analogous to “pixels” which represent pictureelements). The height of a fingel is defined to be 1/256th of the lengthof an ISO memory smart card and the width is defined to be 1/128th ofthe width of an ISO memory smart card. The behaviour associated witheach element may be modified with one or more flags. Each user interfaceelement preferably has four associated flags as follows:

(i) Invert Beep Enable;

(ii) Auto repeats;

(iii) Do Not Send Data on Press; and

(iv) Do Not Send Data on Release.

FIG. 18 shows a description for each of the user interface elementflags.

4.2.2 Card Data

The Card Data object is used to store data which is specific to aparticular card. The data layout for this object has no fixed form. Thecontents of the Card Data object are sent from the reader 1 as part ofthe INSERT message when the card 10 is inserted into the reader 1.

4.2.3 Fixed Length Data

The fixed length data object is used to define a fixed length block onthe card that can be written to by the computer 100, for example.

4.2.4 Reader Insert

The reader insert object is used to store instructions for the remotereader 1 when a particular card is inserted. This can be used, forexample, to instruct the reader 1 to use a specific configuration of IRcommands to allow communication with a specific set top box or TV.

4.2.5 No Operation

The No Operation object is used to fill in unused sections between otherobjects on a particular card. Any data stored in the no operation objectis ignored by the remote reader 1. Any unused space at the end of thecard 10 does not need to be filled in with a no operation object.

4.2.6 No Operation (One Byte)

The No Operation (One Byte) object is used to fill gaps between objectsthat are too small for a full object structure. These objects are onlyone byte long in total.

5.0 Reader Protocol

The remote reader 1 uses a datagram protocol that supports bothunidirectional and bi-directional communication between the remotereader 1 and the set top box 601 or computer 100, for example. Theformat used for messages from the remote reader 1 as a result of userinteractions with the remote reader 1 are of a different format thanthose that are sent to the remote reader 1.

5.1 Message Types

There are at least seven message event types that can be sent by theremote reader 1. These events are as follows:

-   -   INSERT: When a card 10 is inserted into the remote reader 1, and        the card 10 is validated, an INSERT event is generated by the        remote reader 1 and an associated message is transmitted. This        message announces the card 10 to a receiver (e.g. the set top        box 601). The INSERT message preferably includes the particular        distinguishing identifier and allows applications to be started        or fetched immediately upon card 10 insertion rather than        waiting until the first interaction takes place. The INSERT        message preferably includes the contents of the card data object        from the card 10 inserted into the reader 1 if an object of this        type is present on the card 10.    -   REMOVE: When a card 10 is removed from the remote reader 1, a        corresponding REMOVE event is generated and a REMOVE message is        sent to the particular receiver associated with the remote        reader 1. Like the INSERT message, the associated distinguishing        identifier is transmitted along with the message. As the        distinguishing identifier cannot be read from the now removed        card 10, the distinguishing identifier is stored in the memory        47 of the remote reader 1. This is a useful optimisation as the        distinguishing identifier is required for all other messages and        reading the distinguishing identifier from the card 10 each time        the distinguishing identifier is required can be too slow.        INSERT and REMOVE messages are not relied upon by the system 600        to control processing. The system 600 is configured to infer        missing messages if a message is received and is not immediately        expected. For example, if an application detects two INSERT        messages in a row, then an application can assume that it has        missed the REMOVE message associated with the card of the first        INSERT message as it is not possible to have two cards inserted        at one time in present arrangement. The application can then        take whatever action is required prior to processing the second        INSERT message.    -   Another example of where a missing message can occur is where a        hand-held, infrared connected reader 1, as compared with a wired        reader, is being used. Often a user does not point the reader 1        directly at a receiver when inserting or removing cards. This        problem can be corrected by the system 600 inferring the INSERT        or REMOVE operations based on differing distinguishing        identifiers in consecutive PRESS and RELEASE pairs.    -   BAD CARD: If an invalid card is inserted, then the remote reader        1 is preferably configured to generate a BAD CARD event and to        send a BAD CARD message. This message allows an associated        receiver to take some action to alert the user to the invalid        card.    -   PRESS: When a touch is detected by the remote reader 1, a PRESS        event is generated and a PRESS message is sent to an associated        receiver. The PRESS message contains details of the associated        card, the position of the press and the data associated with the        user-interface element at that particular position. If there is        no user interface element defined for that position (including        if there is no user interface elements defined on the card 10 at        all) a PRESS message is sent containing details of the        associated card and the position of the press. If there is no        card present in the remote reader 1 when a PRESS event is        generated then a PRESS message is sent containing the special        “NO_CARD” identifier (i.e. eight bytes of zero—0x00) and the        position of the press.    -   RELEASE: A RELEASE event complements the PRESS event and a        RELEASE message can be sent in order to inform the application        program of the system 600 that a PRESS has been lifted. Every        PRESS event preferably has a corresponding RELEASE event.        Readers can allow multiple presses to be registered or provide        other events that may occur between PRESS and RELEASE messages.    -   MOVE: If, after processing a PRESS event, the touch position        changes by a certain amount then the finger (or whatever is        being used to touch the card) is assumed to be moving. MOVE        EVENTS are generated and MOVE messages are sent until the touch        is lifted. MOVE events auto-repeat by re-sending the last MOVE        messages when the touch position remains stationary. The        repeated sending finishes when the touch is lifted and a        corresponding RELEASE message is sent. Unlike PRESS and RELEASE        events there is no user-interface object involved with MOVE        events.    -   LOW BATT: A LOW BATT event is generated and a LOW BATT message        is sent when the battery 53 in the remote reader 1 is getting        low. This message is sent after user interactions to increase        the chance that the message will be received by the rest of the        system 600. The sending of the LOW BATT message does not prevent        the remote reader 1 from entering a low power state.        5.2 Data Formats

The preferred data format of the reader protocol used in the system 600is a fixed size header followed by a variable length data field whichcan be zero bytes or more in length, followed by an eight bit check-sumand complement.

5.2.1 Message Header

The message header is preferably of a fixed length and is prepended(i.e. appended to, but in front of) to all messages sent from the remotereader 1. It is necessary to keep the message header as small aspossible due to any bandwidth restrictions that may be imposed. FIG. 19shows the format of the message header that is sent from a remote reader1.

Service and service-specific identifiers can be assigned, by a smartcard identification authority, to a vendor when the vendor registers aparticular service. The service and service-specific identifier are thesame for every message from a given card. A service specific identifieris preferably set by a vendor for use with their application. The Readeridentifier is also in the header of each message. This identifier can beused by an application 304 to distinguish different users, for example,in a multi-player game.

FIG. 20 shows a table listing the message event types that have beendescribed above.

5.2.2 Simple Messages

A number of message types are considered simple in that they consistsolely of the message header described above followed by the messagechecksum byte and its complement. For example, a BADCARD message, aLOW_BATT message and a REMOVE message are simple messages.

FIG. 21 shows the format of a simple message.

5.2.3 MOVE Messages

MOVE messages are formed of the message header described above followedby two fields defining the co-ordinates of the touch position on thetouch panel 8 of the remote reader 1. FIG. 22 shows the format of a MOVEmessage.

5.2.4 PRESS and RELEASE Messages

FIG. 23 shows the format of PRESS and RELEASE messages. PRESS andRELEASE messages, like MOVE messages contain the message header andtouch co-ordinates. In addition, PRESS and RELEASE messages send dataassociated with the user-interface element if the touch position matchesa user-interface element defined on the card. This data is of variablelength, the actual size being defined by a corresponding card 10. If thetouched position does not match a user-interface element defined on thecard (including if no user-interface elements are defined on the card),zero bytes of data associated with user interface elements are sent. Ifthere is no card 10 in the reader 1 then the service identifiers are allset to zero (ie 0x00) and zero bytes of data associated with theuser-interface elements are sent. The data associated with the userinterface element normally corresponds to the data associated with theuser interface element defined on the card but may be modified orgenerated by processing on the card 10 or reader 1.

FIG. 24 is a data flow diagram showing the flow of the above-describedmessages within the system 600. As seen in FIG. 24, the card header 1100and object structure 5713 are read by the CPU 45 of the remote reader 1which sends a corresponding INSERT, REMOVE, PRESS, RELEASE, MOVE,BADCARD or LOW BAT message to the event manager 301 via the I/O daemon300. As will be described in more detail below, the event manager 301has twenty-one core messages, which are sent to and received from the ML302, launcher 303 and applications 304.

5.2.5 INSERT Messages

INSERT messages are formed of the message header described above and thecontents of the card data object from the inserted card 10. FIG. 21Ashows the format of an INSERT message.

6.0 Reader Firmware

6.1 Overview

The microcontroller 44 has non-volatile memory 46 embedded within whichcan be programmed with the firmware to be described in detail below. Thefirmware working in concert with the microcontroller 44 and peripheralhardware (e.g. the computer 100) can thus dictate the functionalrequirements of the remote reader 1.

6.2 Code Type

In an attempt to minimise the cost of the remote reader 1 to a user,memory on the remote reader 1 is preferably minimised. As a result theapplication program written for the remote reader 1(i.e. the firmware)must be as compact and fast as is possible.

6.3 Resource Constraints

The microcontroller 44 has the following characteristics:

6.3.1 Non-volatile Memory

The flash memory 46 is configured with 4096 bytes of FLASH ROM and canbe utilised for firmware storage. The FLASH ROM is re-programmable butin the case of mass production a MASK ROM part can be utilised.

6.3.2 Random Access Memory (RAM)

The RAM 47 is configured as 128 bytes of RAM for use by the firmware.

6.4 Interrupts

The remote reader 1 uses two of the numerous interrupt sources supportedby the microcontroller 44. These interrupts can be described as follows:

6.4.1 Received Data Interrupt

An infrared (IR) serial data receiver generally generates a falling edgewhen incoming data is received. This data has to be sampled and bufferedas quickly as possible. One port of the microcontroller 44 doubles as aninput timing capture pin which can initiate an interrupt on the fallingedge.

6.4.2 Timer Overflow Interrupt

The microcontroller 44 has a free-running 16-bit timer which can beprogrammed to generate an interrupt when it overflows. In conjunctionwith the 4.91 MHz clock source and pre-scale factor of 64, this equatesto an interrupt every 3.41 seconds. An interrupt service routineincrements a counter which triggers the suspension to low power modepreferably after about one minute of inactivity.

6.5 Resets

The microcontroller 44 supports five reset sources and the remote reader1 is preferably configured to use all of reset sources. These resetsources can be described as follows:

6.5.1 Power On Reset (POR)

The POR reset is initiated when a new battery is fitted to the remotereader 1. The microcontroller 44 includes a circuit that detects thepower on condition and generates a reset.

6.5.2 Low Voltage Inhibit (LVI) Reset

The LVI reset is initiated when a circuit (not shown) within themicrocontroller 44 detects that the supply voltage has fallen below 2.4Volts. When this kind of reset occurs a flag is set in a Reset StatusRegister (RSR) and an initialisation routine can deduce that the battery53 is becoming depleted. For example, when infrared data is beingtransmitted, the infrared LED consumes high current as it is beingpulsed. If the battery 53 is depleted, the supply voltage can dip underthe 2.4 Volt threshold during transmission causing an LVI reset. Afterreset the battery 53 voltage recovers and the LVI reset does not occuruntil the next high current drain. This gives the remote reader 1 achance to flag the failing of the battery 53 to an associated set-topbox or remote equipment so that the user can be prompted to replace thebattery 53.

6.5.3 Computer Operating Properly (COP) Reset

The COP reset is configured to reset the microcontroller 44 if themicrocontroller 44 gets stuck doing a particular operation for aninordinate amount of time. The COP circuit takes the form of a counterthat generates a reset if the counter is allowed to over-flow. The COPregister must be written at predetermined time intervals to avoid a COPreset.

6.5.4 Illegal Address/Opcode Reset

An Illegal Address/Opcode Reset is generated by the microcontroller 44if it encounters either an address out of a predetermined range or anopcode that does not conform to predefined conditions. This reset cannotbe turned off but should only be in evidence during code debugging.

6.5.5 Hardware Reset

A hardware reset is generated by driving a ‘Reset’ pin on themicrocontroller 44 low during normal operation. Additionally, if themicrocontroller 44 is in low power mode, a falling edge on the InterruptRequest (IRQ) pin also generates a hardware reset. This reset is themechanism used to wake the microcontroller 44 out of low power mode inthe firmware. The IRQ pin is preferable for this function since it canbe configured to be edge sensitive only, not level sensitive as thereset pin is.

6.6 Memory Card/CPU Card Interface

The firmware preferably supports only memory card peripherals using anIntegrated Circuit Protocol (e.g. the I²C protocol). Alternatively, thefirmware can support CPU card formats.

6.7 Power Consumption

The firmware plays a critical role in conserving the life of the battery53. All operations performed by the microcontroller 44 are optimised soas to be performed as quickly as possible while wasting as little poweras possible. As soon as the remote reader 1 has been inactive for a time(e.g. 1 minute) the microcontroller 44 suspends to low power mode toconserve battery life still further. Low power mode consumes about 1000times less current than normal operating mode so efficient suspension tothis mode is very desirable. The firmware controls the state of themicrocontroller 44 ports during low power mode.

6.8 Device Programming

The microcontroller 44 is able to be programmed using an In-Systemprogram (ISP) function supported by an embedded monitor within themicrocontroller 44. Monitor code is typically factory set by amanufacturer and can not be altered.

Programming of the microcontroller 44 for specific hardware can beperformed using an In-Circuit Simulator (ICS) kit and a monitor-modedownload cable. This cable uses the VCC, GND, RST, IRQ and PTB0 pins onthe microcontroller 44. Source code to be programmed can be delivered,for example, from a Windows™ 95 development environment via a computerserial port to the ICS hardware and from there via the download cable tothe microcontroller 44 pins. This programming method is ideal forfirmware development and testing, but may be altered for massproduction. A monitor-mode programming model is preferred in themicrocontroller and an embedded programming jig for production can beused. Test points for programming signals can be provided to allow forproduction ISP. If the firmware is mask programmed into themicrocontroller 44 then device programming will not be required.

6.9 Firmware Programming Sequence

The programming of the firmware will be described with reference to thereader 1 being operative coupled to a local computer 100.

6.9.1 The Main Loop

FIG. 25 is a flow diagram showing the read method 2500 performed by theremote reader 1 of the system 600 incorporating the softwarearchitecture 200. The method 2500 begins after a reset event, asdescribed above, has been generated and the method 2500 is executed bythe CPU 45. The method of FIG. 25 is configured in a “paced loop”manner. That is, the method 2500 is paced by a routine, which generatesa 10 ms delay. This delay gives adequate service to the necessaryroutines while providing good latency for the handling of interrupts.

At the first step 2600, an initialisation routine is performed by theCPU 45. The initialisation routine is performed in order to initialiseconfiguration registers and will be explained below with reference tothe flow diagram of FIG. 26. The method 2500 continues at the next step2501, where the computer operating properly (COP) register is clearedindicating that the firmware is not stuck in any recurring loops. At thenext step 2700 a check card process is performed by the CPU 45, in orderto check for any changes in the presence and validity of a particularsmart card 10. The check card process will be explained in more detailbelow with reference to the flow diagram of FIG. 27. The method 2500continues at the next step 2800, where a scan touch panel process isperformed by the CPU 45 to check for any touches on the touch panel 8 bythe user. At the next step 2900, a wait 10 ms routine is performed bythe CPU 45, and the method 2500 then returns to step 2501.

6.9.1 The Initialisation Process

After a reset from any one of the five sources described above allconfiguration registers require correct initialisation. If an LVI resetwas received then a “possibly depleted battery” flag is set. FIG. 26 isa flow diagram showing a method 2600 of initialising the system 600incorporating the software architecture 200. The method 2600 is executedby the CPU 45 and begins at step 2601 where all registers areinitialised to a predetermined default state. At the next step 2602, acheck is performed by the CPU 45 to determine if the reset was an LVIreset. If the reset was not an LVI reset at step 2602, then the method2600 concludes. Otherwise the method 2600 proceeds to step 2603 wherethe possibly depleted battery flag is set and then the method 2600concludes.

6.9.2 The Check Card Process

FIG. 27 is a flow diagram showing a method 2700 of checking the card 10of the system 600 incorporating the software architecture 200. Asdescribed above, the method 2700 checks for changes in the presence andvalidity of a smart card 10 in the remote reader 1 and respondsaccordingly. The method 2700 is performed by the CPU 45 and begins atstep 701 where if a smart card 10 is inserted in the remote reader 1,then the method 2700 proceeds to step 702. At step 702, if the card 10is a new card (i.e. in the previous state there was no card in thereader 1), then the method 2700 proceeds to step 703. Otherwise, themethod 2700 concludes. At the next step 703, the “magic number” and“checksum” fields are read from the card header stored in the memory 19of the card 10, and are checked for correctness. If the “magic number”and “checksum” are correct, then the method 2700 proceeds to step 704.The method 2700 continues at step 704, where the distinguishingidentifier is read from the card header and the “No MOVE events” and “NoEvent Co-ordinates” flags are set. The Card Data, if present, is alsoread from the card at this step 704. At the next step 705, an INSERTmessage, including the Card Data if present, is sent to computer 100,and the INSERT message is processed by the CPU 205. Then at step 706, a“BEEP” is sounded and the method 2700 concludes.

If the “magic number” and “checksum” fields are not correct (ie: thecard 10 is not valid) at step 703, then the method 2700 proceeds to step710 where the don't beep, no move events and event co-ordinate flags areset. At the next step 711, a BAD CARD message is sent to the computer100, and the BAD CARD message is processed by the CPU 205. Then at step712, a “BOOP” is sounded and the method 2700 concludes.

If a smart card 10 is not inserted in the remote reader 1 at step 701,then the method 2700 proceeds to step 707. At step 707, if this is thefirst operation of the reader 1 after the reset then the method 2700concludes. Otherwise, the method 2700 proceeds to step 708 where the“Don't beep”, “No MOVE Events” and “No Event Co-ordinates” flags are setand the distinguishing identifier stored in memory 47 is set to“NO_CARD”. At the next step 709, a REMOVE message is sent to thecomputer 100, and the REMOVE message is processed by the CPU 205. Themethod 2700 concludes after step 709.

6.9.3 The Scan Touch Panel Routine

FIG. 28 is a flow diagram showing a method 2800 of scanning the touchpanel 8 of the reader 1 of the system 600 incorporating the softwarearchitecture 200. As described above, the scan touch panel routinechecks for touch panel touches that equate with card button presses andresponds accordingly. The method 2800 is executed by the CPU 45 andbegins at step 801 where if the panel 8 is being touched, then themethod 2800 proceeds to step 802. Otherwise, the method 2800 proceeds tostep 812, where if the panel 8 has been touched previously then themethod 2800 proceeds to step 813. Otherwise, the method 2800 concludes.

At step 813, the “don't beep”, “no move events” and “event co-ordinate”flags are set. Then at step 814, the message type is set to RELEASE andthe method 2800 proceeds to step 805.

The method 2800 continues at step 802, where if this is the first timethat the touch has been noticed since there was no touch, then themethod 2800 proceeds to step 803. At the next step 803, the CPU45determines if a bad card has been inserted into the reader 1 by checkingthe result of step 703, then in the case that a bad card has beeninserted into the reader 1, the method 2800 proceeds to step 815. Thenat step 815, a BAD Card message is sent to the computer 100, the BADCARD message is stored in memory 206, and the method 2800 concludes. Ifit was determined at step 803 that the card 10 was valid, by checkingthe result of step 703, or that no card was inserted into the reader 1,by the checking of step 701, then the method 2800 proceeds to step 804,where the type of message is set to PRESS in the message header of FIG.19. At the next step 805, the CPU45 determines the touch coordinates(i.e. X, Y coordinates of user press location) via the touch panelinterface 41. Then at the next step 807, the offset and scale functionsare applied to the coordinates. The offset and scale functions map thecoordinate space of the touch panel 8 to the coordinate space of thecard 10. The method 2800 continues at the next step 807, where if theCPU45 determines that the sent message was a MOVE and/or no card wasinserted into the reader 1, by checking step 701, then the method 2800proceeds directly to step 809. Otherwise, the method 2800 proceeds tostep 808 and the memory 19 of the card 10 is searched in order to findthe first user interface element whose X1, Y1, X2, Y2 values form arange within which the touch coordinates fall and data associated withmatched user interface element is read from the card 10. At the step809, the message is sent along with any data to the associated computer100, and the CPU 205 in the computer 100 processes the message. Themethod 2800 continues at the next step 811, where a BEEP sound issounded and the method 2800 concludes.

If this is not the first time that a touch has been noticed since therewas no touch, at step 802, then the method 2800 proceeds to step 816. Atstep 816, if the touch detected at step 801 was a move, then the method2800 proceeds to step 817. Otherwise the method 2800 concludes. At step817, the message type is set to MOVE and the method 2800 proceeds tostep 805. For example, a MOVE message can be sent along with the X, Ycoordinates of a touch position as defined by FIGS. 19 and 22, a PRESSand RELEASE message can be sent along with X, Y coordinates of a touchposition and data associated with a user interface object (i.e. one ofIndicia 14) as defined by FIGS. 19 and 23. If it was determined at step807 that the message was a MOVE, at step 809, then the CPU 45 sends aMOVE message to the computer 100. The CPU205 processes X, Y coordinatesas cursor information and moves a cursor that is displayed on the VideoDisplay 101. In this case, the next RELEASE message can be interpretedas a command to select the displayed object at the cursor position (egto execute a program, select an item or load a URL). Further, if NOEvent Coordinates (see FIG. 13) have been set in the card 10, then thereader 1 may send the data associated with a user interface object tothe event manager 301 in the computer 100 or STB 601 without sending theX, Y coordinates of the touch position.

In addition, if the application 304 has a user interface Objectstructure such as that shown in FIG. 17, and a matching function such asat step 808, then the reader 1 may send X, Y coordinates of a touchposition to the application 304. As a result, the CPU 205 executes thesame matching function to read data associated with the user interfaceobject from the event manager 301 and provides the card user, a service(e.g. game) identified by a service identifier 1106 associated with theread data. For example, at step 4205 of FIG. 41, the CPU205 determinesif data is in the data field of a message. If data is in the data field,then CPU205 reads the data and processes the data at the next steps inFIG. 41. If data is not in the data field, then the CPU205 reads the X,Y coordinates from the message and executes the matching function forthe coordinates to get data associated with user pressed indicia.Alternatively, the event manager 301, using the user interface objectstructure available to the event manager 301, can perform this function.

Therefore, if a card user uses the reader 1 (without inserting a card10) as a mouse by moving his or her finger on the touch panel 8, theuser can select one of the STB services on a STB menu displayed on theTV display. Also, if the card user uses the reader 1 with an insertedcard 10 and selects some indicia 14, the user receives a service (e.g.game) from the computer 100 or STB 601. In particular, if the userselects a START indicia, a desired game can be executed in the computer100 or STB 601 and an object in the game kicks a ball according to theselection of a KICK indicia 14.

By defining per-card flag values in advance for the card 10, varioustypes of cards 10 can be provided to a user. For example, if a flag(i.e. information) of “NO Move Events” has been set in a card 10 inadvance, the reader 1 can be configured to not perform as a mouse basedon the flag. On the other hand, if a flag of “NO Move Events” has notbeen set in the card 10 in advance, then the reader 1 can be configuredto perform as a mouse based on the flag.

As shown in FIG. 13, the reader 1 has a default condition in which thereader 1 provides audio feedback, acts as a mouse and sends coordinatesfor press, release and more events. Alternatively, the reader 1 canprovide a default condition in which the reader 1 does not provide audiofeedback, act as a mouse and send coordinates.

If the reader 1 is configured to perform the ‘beep function’ using theper-card flag values, the reader 1 sounds a “beep” and executes a methodin accordance with the flow diagrams shown in FIGS. 27 and 28. Further,if the reader 1 is configured to perform the ‘mouse function’ using theper-card flag values, then the reader 1 acts as a mouse and executes amethod in accordance with the flow diagrams of FIGS. 27 and 28. Stillfurther, if the reader 1 is configured to perform the ‘matchingfunction’ using the per-card flag values, then the reader 1 sendscoordinates for press, release and move events and executes a method inaccordance with the flow diagrams of FIGS. 27 and 28.

The matching function is also executed in the EM301 as at step 808 ofFIG. 28. The card 10 can also be configured as a card having only themouse function and/or a basic function (e.g. sending the EM301 dataassociated with indicia selected by a user). Therefore, by combiningeach per-card flag value randomly, various types of cards 10 can beprovided to a user.

As described herein, the service identifier 1106 is an indispensableidentifier for the system 600. By sending at least a service identifier1106 in the distinguishing identifier 1110, to the EM 301, a service canbe provided to a user.

The service specific identifier 1107 described above is preferably setby a vendor for use with a particular application. Therefore, if thevendor defines a unique service specific identifier 1107 for each card10, then the card 10 would be unique. If the service specific identifier1107 is being used to provide information about a means by whichparticular cards have been distributed (e.g. by mail, handed out on atrain), then the service specific identifier 1107 can be added to a filewhich gives a record of which cards have been used to access the servicefor later use in determining how effective different distribution meanshave been used.

6.9.4 The Wait 10 ms Process

FIG. 29 is a flow diagram showing a wait 10 ms routine 2900. The wait 10ms routine 2900 loops so as to consume CPU cycles until 10 ms haselapsed. The delay process 2900 is executed by the CPU 45 and begins atstep 901 where a predefined process counter is cleared. At the next step902, the counter is incremented. Then at the step 903, if 10 ms has notelapsed, then the method 2900 returns to step 902. Otherwise the delayprocess 2900 concludes.

7.0 Event Manager

The event manager 301 is one of the process components of the softwarearchitecture 200. The event manager 301 enforces the rules of thearchitecture 200 and ensures consistent behaviour between the otherprocess components.

7.1 Role in the System

Most communications pass through the event manager 301 and the eventmanager 301 is the only component of the architecture 200 that allprocess components except the directory service 311 components need tobe able to directly communicate with. The event manager 301 acts as theenforcer of the rules of the architecture 200, and the event manager 301does not necessarily have to be configured as one distinct program. Theevent manager 301 can also be formed of trusted relays or other separateprocess components that perform part of the event manager role. This canbe done for efficiency or security reasons for example.

The event manager 301 may incorporate various other parts of thesoftware architecture 200 such as the I/O daemon 300 and the launcher303. The event manager 310 may even incorporate an application such as abrowser controller.

The event manager 301 can communicate with every process component ofthe system 600 except the directory service 311 either directly orthrough a trusted relay. These components include the I/O daemon 300,launcher 303 and any of the applications 304. The event manager 301 canuse any suitable communications method to communicate with the otherprocess components. The preferred communication method is TransmissionControl Protocol/Internet Protocol (TCP/IP) due to it's nearly universalimplementation but other OS specific methods, such as Unix™ sockets, etccan also be used. When the process components are integrated togetherthe method used to communicate can be internal data passing betweenseparate threads.

The event manager 301 is preferably configured to be immune tointerference from other process components which includes otherprocesses being able to kill the event manager 301 or being able tostarve the event manager 301 of CPU time or network bandwidth. Thisensures that the event manager 301 can remain in ultimate control of thesystem 600.

7.2 Internal Requirements

The event manager 301 performs non-blocking I/O to all the other processcomponents 300, 303, 304 and 306 of the architecture 200 by methods suchas polling (NB: polling is not recommended due to the CPU load),interrupt driven I/O, having a separate thread reading and writing fromeach component or any other suitable method that achieves the same goal.This ensures that one component is not starved out by another componentand also reduces user wait time.

The event manager 301 is also configured to check all incoming data forvalidity and to repair the data if possible before output. This includesdata from trusted components. The event manager 301 is preferably alsofail safe. If the event manager 301 receives unexpected data from one ofthe components 300, 303, 304, or 306, then the event manager 301 isconfigured to deal with the data and not exit unless it is absolutelyunavoidable.

The event manager 301 can be required to be running for a considerablelength of time and it is configured so as to ensure that performancedoes not degrade over time. The event manager 301 is preferablyconfigured to assume that the transmission mechanism is reliable forcommunication with any component that is using a predetermined eventmanager protocol (i.e. EM-protocol) but assumes that the transmissionmechanism used to communicate with the remote reader 1, via the I/Odaemon 300, is unreliable and parts of the incoming data may beincorrect or missing.

7.3 Procedures

The event manager 301 is a direct participant in some of the operationsof the system 600 but also transparently takes part in many of the otheroperations of the architecture 200. The event manager 301 is transparentin that it uses data packets as they pass through it without modifyingthem. The procedures will be explained in more detail below particularlywith reference to section 8.0.

FIG. 30 is a flow diagram showing an overview process 3010 of eventsperformed by the system 600 incorporating the software architecture 200.The process 3010, is executed by the CPU 205 depending on theconfiguration of the system 600. The process 3010 begins at step 3000where a system initialisation routine is performed, with theinitialisation routine including starting the event manager 301. At step3000 the I/O daemon is typically also started with the event manager301.

At the next step 3700 the event manager 301 starts the launcher 303.Then at the step 3300, the event manager 301 passes a message to thelauncher 303, enabling the launcher 303 to determine which application304 to execute, and the launcher 303 then starts the correspondingapplication 304. The process 3010 continues at the next step 3400, whereonce the currently running application 304 is no longer needed, forinstance, when a new card 10 is inserted into the reader 1, the launcher303 provides an exit message to the running application in order to endthe execution of the running application. All applications areterminated when the system 600 is powered down (or switched off).

FIG. 31 is a flow diagram showing a method 3000 of receiving an eventperformed by the event manager 301. The method 3000 can be executed bythe CPU 205 for computer implementations. Alternatively, the method 3000can be executed by the CPU 4305 in set top box implementations. Themethod 3000 begins at step 3101, where the launcher 303 is started. Atthe next step 3103, the event manager 301 receives an event. If theevent received at step 3103 is not from the remote reader 1 at the nextstep 3105, then the method 3000 proceeds to step 3107 where thecomponent identifier (XID) is checked and corrected if necessary. Themethod 3000 continues at the next step 3109, where if the newapplication sending an event is allowed to send the event, then themethod 3000 proceeds to step 3111. At step 3111, the event is sent to adestination process component and the method 3000 returns to step 3103.If the sending application is not allowed to send the event at step3109, then the method 3000 proceeds to step 3113, where the event isdropped and the method 3000 returns to step 3103.

If the event is from the remote reader 1 at step 3105, then the method3000 proceeds to step 3115. If the event is a BADCARD, LOWBAT, INSERT orREMOVE event at step 3115 then the method 3000 proceeds to step 3117.Otherwise the method 3000 proceeds to step 3119. At step 3117, the eventis passed to the launcher 303 and the method 3000 returns to step 3103.If the distinguishing identifier is the NO_CARD identifier at step 3119,then the corresponding message is passed to the launcher 303 at step3117. Otherwise the method 3000 proceeds to step 3121, where the serviceidentifier portion of the distinguishing identifier is compared with theservice identifier used in determining the current front application. Ifthe service identifier is not the same as that which has been used todetermine the front application and the service identifier portion ofthe distinguishing identifier is not the special generic serviceidentifier, then the method 3000 proceeds to step 3117 where thismessage is passed to launcher 303. Otherwise, the method 3000 proceedsto step 3123, where the event is sent to the front application and themethod 3000 returns to step 3103.

7.4 Focus Change

The event manager 301 can safely ignore any EM_LOSING_FOCUS events thatare not for the current front application. The event manager 301 needsto watch for EM_GAINING_FOCUS messages for which applications becomingthe front application as well as the service identifiers that areassociated with that application. The event manager 301 can safelyignore multiple EM_GAINING_FOCUS events that are to the same applicationwith the same service identifier as well as any EM_LOSING_FOCUS eventsto applications that are not the currently front application. Messagesthat are ignored are passed on as normal.

7.5 Reader Messages

The event manager 301 is also responsible for distributing the messagesto the correct component The event manager 301 is configured to followcertain predetermined protocol rules, which will be described in detailbelow.

7.6 Restrictions on Sending Messages

A further role of the event manager 301 is to enforce predeterminedrestrictions on the transmitting of messages.

8.0 Event Manager Protocol

The event manager protocol (EM-protocol) is the protocol used tocommunicate between all components of the architecture 200 except forthe directory service 311. Generally all messages are configured to gothrough the event manager 301 before being passed onto an intendedrecipient The EM-protocol is a datagram based protocol that isimplemented on top of a reliable communications protocol, for example,Transport Control Protocol/Internet Protocol (TCP/IP). The event manager301 is configured to assume that all data being sent will arriveunchanged and in the correct order. The event manager 301 does notassume that there is a reliable method of synchronisation between theprocess components of the architecture 200.

All multi-byte values are sent in Internet byte order (i.e. big-endian).The exception to this is the ‘distinguishing identifier’ valuesrepresenting services, which are sent as blocks of several single bytesand are always treated as such (i.e. the distinguishing identifiervalues are never stored as a number typically because of the byteordering issues).

8.1 Communication Methods

The event manager protocol is preferably configured to assume a TCP/IPlike method of communication between the components of the architecture200 and the system 600 hardware components. Alternatively, any knownmethod of communication that ensures reliable transport can be used. Forexample, an operating system specific method such as ‘Unix sockets’ canbe used. The data can be passed between the process components 301, 303,304 and 306 directly via internal data structures in a multi-threadedapplication, for example.

In the case of architectures where an alternative method ofcommunication between the components is being used, the problem ofbyte-ordering must be taken into account. If it is possible thatapplications can run on a machine that has different byte orderings oris required to communicate with components that expect the data innetwork byte order, which all components assume by default, then allaffected communications can be done in network byte order.

8.2 Data Format

8.2.1 Basic Data Types

Some abbreviations that are used in the following paragraphs to refer todata types are as follows:

-   -   int8: An eight bit signed value;    -   uint8: An eight bit unsigned value;    -   int16: A 16 bit signed value;    -   uint16: A 16 bit unsigned value;    -   int32: A 32 bit signed value;    -   uint32: A 32 bit unsigned value; and    -   xid_t: A 32 bit unsigned value.        8.2.2 Component Addressing

Every addressable process component in the architecture 200 is assigneda 32 bit unsigned value referred to as an ‘xid’ (or componentidentifier). This number is unique within the boundaries of eachindividual system 600 instance. Some xids of the process components arealways the same. These are:

-   -   Event Manager 301: EM_EVENT_MANGER_XID    -   Master Launcher: EM_MASTER_LAUNCHER_XID    -   Launcher 303: EM_FIRST_APP_XID    -   Display Manager 306: EM_DISPLAY_MANAGER_XID

The xid value is divided up into a one byte type field and a three byteidentifier. The different types are shown in Table 1 below.

TABLE 1 Value Type Internal xid's These xid values are not routable andcan be used internally by all components. They are dropped if seen bythe EM Core System xid's These identify the core system components of auser interface Card system. These components include the EM, Launcherand Master Launcher. Standard Application These identify standardapplications that are started and ended by the Launcher as needed.Special application These identify special applications that aren'tcontrolled by the standard rules for starting and ending applications.They are applications that are written to provide the user interfacecard system with functionality that can be controlled by otherapplications such as a video on demand player or a browser controller.Readers Readers are assigned xids by the EM. These xids are unique toeach reader that is used to access the system for the duration of theEM. If the event manager and therefore the system is restarted then thereader xids will change.8.3 Message Types

There are twenty-two core messages in the EM-protocol, which preferablyhave the following labels:

-   -   EM_NEW_LAUNCHER    -   EM_KILL_LAUNCHER    -   EM_APP_REGISTER    -   EM_EXIT_NOW    -   EM_CLOSE    -   EM_APP_STARTING    -   EM_APP_DYING    -   EM_GAG_FOCUS    -   EM_LOSING_FOCUS    -   EM_LIST_MESSAGES    -   EM_LIST_APPS    -   EM_SEND_MESSAGE    -   EM_POST_MESSAGE    -   EM_GET_MESSAGE    -   EM_DELETE_MESSAGE    -   EM_READER_INSERT    -   EM_READER_REMOVE    -   EM_READER_BADCARD    -   EM_READER_MOVE    -   EM_READER_PRESS    -   EM_READER_RELEASE    -   EM_READER_LOW_BATT

These messages will be explained in more detail in the followingparagraphs.

8.3.1 Message Header

The messages sent within the system 600 have a header portion preferablyincluding the following information:

-   version: This represents the version number of the protocol being    used by the component This should always be set to    EM_PROTOCOL_VERSION, which is defined in library headers to be the    version used by the library.-   type: This represents the type of message that a header proceeds and    is set to one of the message types listed above and described below.    The length of the messages is assigned the label dataLength.-   reserved: This represents that the value in these two bytes is    reserved and should be set to zero.-   timestamp: This represents the timestamp of a data packet.-   to_xid: This represents the destination xid of a particular packet.    This is the final destination of the packet and should only be set    to the event manager if that is the intended final recipient.-   from_xid: This represents the source xid of the packet.-   dataLength: This represents the length of the data that follows a    header. This value can be zero. Different types of messages impose    different requirements on the data following the message header.    Components should not assume the length of a message from the type.    The number of bytes in the dataLength field is always read even if    this is different to the correct size of the message to insure that    the stream can only be corrupted by an incorrect dataLength.    8.3.2 EM_NEW_LAUNCHER

The EM_NEW_LAUNCHER message is sent when the event manager 301 requiresa new launcher 303. This message is only sent between the event manager301 and the Master Launcher if the software architecture 200 includessuch a Master Launcher. The packet containing this message also containsinformation that a new launcher needs to connect to the event manager301. The EM_NEW_LAUNCHER message preferably includes the followinginformation:

-   port: This represents the port number that the event manager 301 is    listening for new connection on.-   host: This represents the host name of the machine running the event    manager 301.    8.3.3 EM_KILL_LAUNCHER

The EM_KILL_LAUNCHER message is sent when the event manager 301 wantsthe Master Launcher to kill the current launcher 303. TheEM_KILL_LAUNCHER message has no data associated with it.

8.3.4 EM_APP_REGISTER

The EM_APP_REGISTER message is sent when an application is starting upto the launcher 303 and informs the rest of the components of thearchitecture 200 that it is now ready to receive messages. Any messagesthat an application 304 sends before it has registered will be discardedby the event manager 301.

The EM_APP_REGISTER message preferably includes the followinginformation:

-   xid: This represents the component identifier that was assigned to    the application by the associated launcher 303. The remainder of the    information sent cannot be represented by the structure as the    remaining fields are of variable length. The data following the xid    is a series of null terminated strings with a maximum length of 256    characters not including the terminating null, consisting of the    lower and upper case characters a-z, the numbers 0-9 and the    characters (.,-_). If the strings are longer than 256 characters    they will be truncated at 256 characters.-   Application Name: this represents a name that is used to identify    the present application to other applications.-   Service Group: this represents one or more names of service groups    that the application wishes to be a part of.

An application that is persistent, such as a browser controller, onlyneeds to register once. Such a persistent application does not need toregister every time it gets an EM_GAINING_FOCUS event.

8.3.5 EM_EXIT_NOW

The EM_EXIT_NOW message is sent by the launcher 303 to an applicationwhen the application is about to be forced to exit. The EM_EXIT_NOWmessage has no data associated with it.

8.3.6 EM_CLOSE

The EM_CLOSE message is sent to persistent applications to indicate thatthe current session is closed and to return the application to itsstartup state. Once this message is received by an application, theapplication is required to treat the next EM_GAINING_FOCUS event as thestart of a new session rather than as a change in input/output focus.The EM_CLOSE message has no associated data.

8.3.7 EM_APP_STARTING

The EM_APP_STARTING message is sent by the launcher 303 to the eventmanager 301 when an application is about to start. The EM_APP_STARTINGmessage preferably includes the following information:

-   xid: This represents the component identifier of the application    that is about to start.    8.3.8 EM_APP_DYING

The EM_APP_DYING message is sent by the launcher 303 to the eventmanager 301 when an application has exited. The EM_APP_DYING message issent only after the launcher 303 is certain that the application hasfinished. The EM_APP_DYING message preferably includes the followinginformation:

-   xid: This represents the component identifier of the application    that has exited.    8.3.9 EM_GAINING_FOCUS

The EM_GAINING_FOCUS message is sent to an application by the launcher303 when the application 304 is about to start receiving input from theremote reader 1. The EM_GAINING_FOCUS message preferably includes thefollowing information:

-   id: This represents the distinguishing identifier of the remote    reader 1 messages that will be sent to an application.-   Data: This represents extra data that is to be sent to the    application when it is about to receive focus. This is specific to    each service and it is up to the application to interpret the data.    The extra data is not checked for byte ordering issues and this    should be dealt with by the application. Any multi-byte data is sent    by applications in network byte order and assumed to be in this    order by the receiving application. An example of this data, when    the receiving application is a browser controller, is a URL which    the browser controller is being instructed to load.    8.3.10 EM_LOSING_FOCUS

The EM_LOSING_FOCUS message is sent when an application 304 is about tolose input/output focus from the remote reader 1 and the display 101.The EM_LOSING_FOCUS message has no extra data.

8.3.11 EM_LIST_APPS

The EM_LIST_APPS message is sent when an application wishes to know whatother applications are also running at a point in time. The EM_LIST_APPSmessage is returned to the application with the data field containingthe application list. This. message does not need to be addressed to anyof the process components 301 to 306. The event manager 301 ensures thatthe EM_LIST_APPS message is sent to the correct component, which isusually the launcher 303, regardless of the to_xid field of the header.It is the role of the receiving component to decide which applicationsto list.

When used as a reply, the EM_LIST_APPS message has two formats. Thefirst is the format used when the EM_LIST_APPS is sent as a request andthe second is the format when it is sent as a reply. The request has noextra data associated with it.

The EM_LIST_APPS message preferably includes the following information:

-   app_xid: This represents the xid of the application being described.-   app_desc: This represents the name string given to the launcher 303    when the application first registers.    8.3.12 EM_SEND_MESSAGE

The EM_SEND_MESSAGE message can be sent between any two concurrentlyrunning applications in the system 600. There is no structure imposed onthis message by the architecture 200 but communicating applications needto agree on a common data structure.

8.3.13 EM_LIST_MESSAGES

The EM_LIST_MESSAGES message is used to get a list of all messagescurrently on a message board, which is used in the architecture 200. Themessage board will be described in more detail below with reference tosection 8.4.7.1. The EM_LIST_MESSAGES message should be sent to thelauncher 303. The EM_LIST_MESSAGES message has a request and replyformat. The request format has no data associated with it. The replypreferably includes the following information:

-   message_count: This represents the number of messages currently on    the message board and can be equal to zero.-   Messages: This represents a variable number (i.e. equal to    message_count) of variable sized structures that have the following    structure:    Each message preferably includes the following information:-   message_id: This represents the message identifier of this message.-   poster_id: This represent the xid (component identifier) of the    component that posted this message.-   mime_type: This represents the Multipurpose Internet Mail    Extention-type (MIME-type) of the data associated with this message    and is a null terminated string which can be of zero length in which    case the terminating zero is still present.-   message_desc:This represents the description of this message that    was assigned when the message was posted by the posting application.    This is a null terminated string that is at most 255 characters long    not including the terminating zero. The length of this string can be    zero in which case the terminating zero is still present.    8.3.14 EM_POST_MESSAGE

The EM_POST_MESSAGE message is used to post some data to the messageboard used in the architecture 200. These messages last until there is aservice group change and can be accessed by any application that isrunning. The EM_POST_MESSAGE messages can also be deleted by anycurrently running application and are not assumed to be totallyreliable. Once the message has been posted it is returned to theapplication that posted it to inform the application of the messageidentifier of the message. These messages are sent to the launcher 303by the application. The message from the application (i.e. theapplication that posted the message) includes the following information:

-   message_desc: This represents a description of the message and is a    null terminated string that can be at most 255 characters long not    including the terminating zero. The description can be zero bytes in    length but must still have a terminating zero.-   mime_type: This represents the MIME type of the message data that is    being posted. The MIME type is not required but there must still be    a terminating zero.-   message_data: This represents the data to be posted to the message    board.

The message returned to the application preferably includes thefollowing information:

-   message_id: This represents the message identifier by which this    message can be retrieved or deleted.    8.3.15 EM_GET_MESSAGE

The EM_GET_MESSAGE message is used to retrieve a message from themessage board. It is sent containing the message identifier of themessage that the component wishes to retrieve and it is returned to thecomponent either containing the message or an error that there is nomessage with that identifier. These messages are sent to the launcher303 by an application 304.

The information included when requesting the message is as follows:

-   message_id: This represents the message identifier of the message    the application wishes to retrieve.-   flags: This is a flags word. All unused bits should be set-to zero.    The flag description is shown in Table 2 below:

TABLE 2 Flag Description Value EM_GM_DELETE Delete the message from themessage 0x01 board after it has been sentThe reply has the following information:

-   error: If an error occurred then this will be set to one of the    values in Table 3 below.

TABLE 3 Value Description EM_GM_NO_ERROR No error occurred. The messageis in the message field. EM_GM_NO_SUCH_MESSAGE No message exists withthat message identifier on the message board.

-   message_id: This represents the message identifier of the message    that was retrieved.-   mime_type: This represents the MIME type of the message that was    retrieved. This is a null terminated string. If this message has no    MIME type associated with it then the string is zero length but the    terminating zero is still present.-   message: If no error occurred then this field will contain the data    posted on the message board. The length is determined by the    dataLength value in the header minus the size of the error field    8.3.16 EM_DELETE_MESSAGE

The EM_DELETE_MESSAGE message is used to delete messages from themessage board. It is not an error to delete a message that does notexist. These messages are sent to the launcher 303 by the frontapplication. The EM_DELETE_MESSAGE preferably includes the followinginformation:

-   message_id: This represents the message identifier of the message    that is to be deleted.    8.3.17 User Interface Card Reader Messages

The user interface card reader messages are generated by the remotereader 1 and are encapsulated by the event manager 301 so that theyconform with the event manager protocol. There are three types ofmessages that are generated by the remote reader 1. These messages are“simple” messages, “move” messages and “press/release” messages. Movemessages are simple messages with co-ordinates added, and press/releasemessages are simple messages with data and coordinates added.

8.3.17.1 Simple Messages

The following messages are simple messages:

-   -   EM_READER_INSERT    -   EM_READER_REMOVE    -   EM_READER_BADCARD    -   EM_READER_LOW_BATT

These simple messages preferably include the following information:

-   id: This represents the distinguishing identifier that was sent by    the remote reader 1 and has no meaning for BADCARD messages.    8.3.17.2 Move Messages

The EM_READER_MOVE messages preferably include the followinginformation:

-   id: This represents the distinguishing identifier that was sent by    the remote reader 1, and is set to all zeros for no card messages.-   X: This represents the x value.-   Y: This represents the y value.    8.3.17.3 Press/Release Messages    EM_READER_PRESS and EM_READER_RELEASE messages preferably includes    the following information:-   id: This represents the distinguishing identifier that was sent by    the remote reader 1.-   x: This represents the x value.-   y: This represents the y value.-   data: This represents any data that was associated with the press or    release (associated with the user interface-element data).    8.4 Procedures

The following paragraphs describe the main procedures that each processcomponent of the architecture 200 follow.

8.4.1 Starting a New Application

FIG. 32 is a flow diagram showing detail of the method 3300 of startinga new application and performed whenever the launcher 303 starts a newapplication. The method 3300 can be executed by the CPU 205 for computerimplementations. Alternatively, the method 3300 can be executed by theCPU 4305 in set top box implementations. The method 3300 begins at thefirst step 3301 where the launcher 303 performs a mapping to translatethe service identifier into a URL. At the next step 3303, the launcher303 fetches and starts the application informing it of an event managerhost-name and port number. The method 3300 continues at the next step3305, where the launcher 303 sends the event manager 301 anEM_APP_STARTING message informing the event manager 301 of the xid ofthe starting application. At the next step 3307, the new applicationconnects to the event manager 301 and sends the launcher 303 anEM_APP_REGISTER message. Further, there is normally a focus change tothe new application.

8.4.2 Ending an Application

FIG. 33 is a flow diagram showing a method 3400 of ending an applicationin the system 600 incorporating the software architecture 200. Themethod 3400 can be executed by the CPU 205 for computer implementations.Alternatively, the method 3400 can be executed by the CPU 4305 in settop box implementations. This method is used whenever the launcher 303terminates a running application. The method 3400 begins at step 3401,where the launcher 303 sends the running application an EM_EXIT_NOWmessage. The launcher 303 sets a time out at this point to give theapplication a chance to exit cleanly. At the next step 3403, the runningapplication cleans up and exits. Alternatively, the application ignoresthe EM_EXIT_NOW message and the launcher 303 times out and forces theapplication to quit. Then at step 3405, the launcher 303 sends the eventmanager 301 an EM_APP_DYING to tell it that the application has exitedand that the launcher 303 should discard any waiting data and close theconnection to the application if the connection is still open, and themethod 3400 concludes.

8.4.3 Closing a Persistent Application's Session

FIG. 34 is a flow diagram showing a method 3500 of closing the currentsession of a persistent application on the system 600 incorporating thesoftware architecture 200. The method 3500 can be executed by the CPU205 for computer implementations. Alternatively, the method 3500 can beexecuted by the CPU 4305 in set top box implementations. The method 3500is analogous to the application ending but the application does notactually close. The method 3500 begins at step 3501, where the launcher303 sends the persistent application an EM_CLOSE message. At the nextstep 3503, the persistent application resets to its initial state, andthe method 3500 concludes. This may involve closing connections tooutside servers, loading a default web page etc. The nextEM_GAINING_FOCUS event that the persistent application receives isassumed to be the start of a new session.

8.4.4 Focus Change

FIG. 35 is a flow diagram showing a method 3600 of performing a focuschange on the system 600 incorporating the software architecture 200.The method 3600 can be executed by the CPU 205 for computerimplementations. Alternatively, the method 3600 can be executed by theCPU 4305 in set top box implementations. The method 3600 is used to tellan application that it is about to gain or lose input/output focus,which is not a signal for the application to exit. At the first step3601, the launcher 303 makes the decision to change the application thatcurrently has input/output focus and sends the application that is toreceive input focus an EM_GAINING_FOCUS event typically based on a cardchange. The sending of this event is used by the event manager 301 todecide which application should receive input/output focus based onpredetermined conditions. Then at the step 3603, the launcher 303 sendsthe previous front application an EM_LOSING_FOCUS event, and the method3600 concludes. This message is less critical and is not sent when thecurrent front application remains the same, but still needs theEM_GAINING_FOCUS (i.e. in the case of a browser controller where theEM_GAINING_FOCUS events are used to tell the browser controller 402 thebase URL).

8.4.5 Message Passing

There are two distinct types of message passing between applicationssupported by the architecture 200. Through the message board that is aspersistent as the current service group, and a direct message methodwhere two components communicate with each other directly as describedbelow.

8.4.5.1 Message Board

One component of the architecture 200, typically the launcher 303,maintains a message board and the event manager 301 knows whichcomponent does this. The message board is formed of a list of messagesthat are assigned a 32 bit unsigned number as an identifier by theprocess component managing the message board. The messages are formed ofa text description, an optional MIME type for the message data and themessage itself. An application can request a list of all messagescurrently on the message board by sending an EM_LIST_MESSAGES message.This will return with the text descriptions of all messages currently onthe message board with their associated message identifiers. Theapplication can then request a specific message by sending aEM_GET_MESSAGE with the message identifier of the message that itrequires. It is possible that a message could be deleted between gettinga listing of the message board and actually requesting a message. Theerror field of the EM_GET_MESSAGE message reply is configured toindicate this.

8.4.5.2 Direct Communication

Two applications can send each other arbitrary data directly, by usingdirect communication. This is performed by one application sending theother application the data by using an EM_SEND_MESSAGE message. The twoapplications need to agree on a data format for these messages and byteordering issues need to be taken into account. To get the componentidentifier of the other application, an application can request to besent a list of all running applications by sending a EM_LIST_APPSmessage. This message returns a list of all publicly visibleapplications that are currently running.

8.5 Reader Messages

This section outlines the rules used by the event manager 301 to routethe EM_READER_* messages. The following messages are always sent to thelauncher 303 regardless of which application currently has focus.

-   -   EM_READER_INSERT    -   EM_READER_REMOVE    -   EM_READER_BADCARD    -   EM_READER_LOW_BATT

The following messages are sent to the currently front application ifthe messages are from cards 10 that have the same service identifier intheir corresponding fields 1106 as the currently front application. Aservice-specific identifier is not taken into account in thiscomparison. If the service identifier is different to the currentlyfront application or the distinguishing identifier is the NO_CARDpresent value (i.e. all zeroes) then the message is sent to the launcher303 as previously described.

-   -   EM_READER_PRESS    -   EM_READER_RELEASE    -   EM_READER_MOVE        8.6 Restrictions on Sending Messages

To improve the security and stability of the system 600, there arepreferably restrictions placed on the sending of messages. Any messagesthat breach these rules will be discarded by the event manager 301.

8.6.1 Restrictions for all Components

No component except the remote reader 1 will be allowed to sendEM_READER_* messages.

8.6.2 Restrictions on the Event Manager

The event manager 301 is the enforcer of the rules and as such can sendany messages necessary. The event manager 301 is configured to only needto generate EM_KILL_LAUNCHER and EM_NEW_LAUNCHER messages but it cancopy messages and send the copies to process components that are not thetarget component. The event manager 301 also handles all transmissionsbetween components.

8.6.3 Restrictions on the Launcher

The launcher 303 sends messages to all components 301 to 306 of thearchitecture 200. The messages that the launcher 303 can not send are asfollows:

-   -   EM_KILL_LAUNCHER    -   EM_NEW_LAUNCHER        8.6.4 Restrictions on Applications

Applications only send the following messages to other applications(which includes the launcher 303):

-   -   EM_APP_REGISTER    -   EM_SEND_MESSAGE    -   EM_LIST_APPS    -   EM_POST_MESSAGE    -   EM_GET_MESSAGE    -   EM_DELETE_MESSAGE    -   EM_LIST_MESSAGES        8.7 Component Procedure Lists

This section lists the functions, which each component of architecture200 is involved in.

8.7.1 Event Manager

The event manager 301 is a direct participant in the followingprocedures:

-   -   System Initialisation    -   System Startup    -   Starting a new Application    -   Ending an Application    -   Focus Change    -   Message Passing    -   Reader Messages        8.7.2 Launcher

The Launcher 303 is a participant in the following procedures:

-   -   System Initialisation    -   System Startup    -   Starting a new Application    -   Ending an Application    -   Focus Change    -   Message Passing (in some instances)    -   Reader Messages (in some instances)        8.7.3 Applications

The Applications 304 are participants in the following procedures:

-   -   Starting a new Application    -   Ending an Application    -   Closing a session if the application is persistent.    -   Focus Change    -   Message Passing    -   Reader Messages (in some instances)        9.0 I/O Daemon

The I/O daemon 300 is responsible for transporting the data being sentfrom the remote reader 1 to the event manager 301, and vice versa for atwo-way protocol. The I/O daemon 300 is configured to be able to readfrom the hardware of the system 600 either directly or through operatingsystem drivers that are interface with the remote reader 1, for example,an IR link or standard serial hardware connection. The I/O daemon 300 isalso required to listen on a TCP/IP port to wait for the event manager301 to connect, at which point the I/O daemon 300 sends data from theremote reader 1 to the event manager 301 encapsulated in a TCP/IPstream.

The I/O daemon 300 does not communicate with the rest of the system 600except to send the remote reader 1 data to the event manager 301, andvice versa in optional two way protocol arrangements between the I/Odaemon 300 and the remote reader 1.

While the functionality of the I/O daemon 300 must be present in thesystem 600, the I/O daemon 300 does not have to be a separate component.For example, the I/O daemon 300 can be integrated into the event manager301 if the event manager 301 is running on the same machine as thehardware used to interface with the remote reader 1.

The I/O daemon 300 is configured to run on minimum hardware for theinstance where the rest of the system 600 is running remotely.

9.1 Requirements

9.1.1 General Requirements

The platform upon which the I/O daemon 300 is implemented must beconfigured be able to receive signals from (and optionally transmitsignals to) a remote reader 1. The platform also preferably has a TCP/IPstack or other reliable communications method implemented on it tocommunicate with the other parts of the system (i.e. the event managerEM) 301). The I/O daemon 300 can be required to do multiplexed I/O, andthe I/O system of the architecture 200 is preferably configured tosupport multiplexed I/O. The architecture 200 is preferably configuredto assign a port that the I/O daemon 300 will be listening on, forexample, as a command line argument.

9.1.2 Internal Requirements

The I/O daemon 300 is not required to understand the protocol used bythe remote reader 1. The I/O daemon 300 is only required to forward alldata that it receives to any listening EM (event manager). The I/Odaemon 300 is not required to correct any errors of transmission fromthe remote reader 1 unless it is supported by the transport protocol ofthe communications link (i.e. through error correcting codes orsimilar). If the transport protocol being used supports error detectionbut not correction then any data that does not pass the error check canbe passed onto the event manager 301.

9.1.3 External Interface Requirements

The I/O daemon 300 is preferably able to accept one or more TCP/IPconnections. The data stream that is sent to the event manager 301 isthe content of the data sent by the remote reader 1. All header andfooter information that is transmitted as part of the communicationsprotocol used is preferably stripped off and the byte ordering is bigendian. If the communication method of the architecture 200 ever becomesunusable (e.g. due to an error arising) then the I/O daemon 300 closesall connections as soon as the error condition arises.

9.2 External Interface

The external interface (not shown) of the I/O daemon 300 isintentionally simplistic to allow it to be run on minimum hardware. TheI/O daemon 300 is preferably configured in the following manner.

9.2.1 Start-Up Procedure

The I/O daemon 300 listens on a TCP/IP port that is specified to it insome manner, for example, by command line arguments. The exact method ofinforming the I/O daemon 300 of the TCP/IP port is implementationspecific. The communications hardware used to communicate with theremote reader 1 is initialised if required and the method to read datathat is sent from the remote reader 1 is configured to be ready toreceive data. While the I/O daemon 300 is waiting for a connection, theI/O daemon 300 consumes the data that is being sent by the remote reader1 so that when a connection is made, only new data is being sent. Thisnew data is not required to start on a message boundary.

9.2.2 Connection from an Event Manager

If a connection arrives on the TCP/IP port then the I/O daemon 300 isconfigured to accept the connection and begin transmitting any datareceived from the remote reader 1 down the connection. If the I/O daemon300 is already connected to an event manager (EM) 301 then the I/Odaemon 300 has two options. Firstly, the I/O daemon can accept theconnection and send all data down all currently connected eventmanagers. This option is provided for system debugging purposes. Thesecond method is to reject the second connection and continue to sendthe data to the already connected EM. Any encryption of the stream canbe handled externally by some other method, such as port tunnelling.

9.2.3 Connection from an Event Manager Closing

If at any time the connection to the event manager 301 is closed, thenthe I/O daemon 300 is configured to discard any data from the remotereader 1 that is waiting to be sent to that event manager 301. If thisis the only event manager connected then the I/O daemon 300 isconfigured to return to an initial startup state whereby the I/O daemon300 consumes data being sent by the remote reader 1 and waits for aconnection.

9.2.4 Unrecoverable Error is Encountered

If the I/O daemon 300 detects an error that cannot be dealt with andwill cause the I/O daemon 300 to exit, then the I/O daemon 300 isconfigured to close all connections to any EMs to inform the EMs thatthe I/O daemon 300 has detected an error. Examples of these errorsinclude if the hardware that is being used to communicate with theremote reader 1 becomes unavailable or if the I/O daemon 300 receives asignal that would cause it to exit. The I/O daemon 300 is configured toclose all connections as soon as an error is experienced.

10.0 Launcher

The launcher 303 is the process component that enforces site specificrules such as allowed applications and basic application configurationrules. The launcher 303 allows the other component processes 300, 301,304, 305 and 306 of the system architecture 200 to be used in a widerange of applications from a general home set top box 601 to a veryspecific application (e.g. an automatic teller machine (ATM)). Alauncher 303 can be specifically written for each network orinstallation.

The launcher 303 is configured with special privileges. For example, thelauncher 303 can be configured to be the first component to connect tothe event manager 301 as the system 600 starts up. Further, the launcher303 receives all “LOW_BATT”, “BADCARD”, “INSERT”, and “REMOVE” messagessent by the remote reader 1 and also receives all “PRESS”, “RELEASE” and“MOVE” messages that originate from a card other than the smart card 10that the front application is associated with at any one point in time.The launcher 303 also receives PRESS, RELEASE and MOVE messages with aspecial “NO_CARD” distinguishing identifier. The launcher 303 also hascontrol over which application is the front application via theEM_GAINING_FOCUS and EM_LOSING_FOCUS events.

The launcher 303 is configured to decide when applications need to bestarted and made to exit. The launcher 303 is also used to start andstop applications although this is not always the case. This role can beundertaken by another application at the instruction of the launcher303, for instance, in the case where the applications 304 are run onseparate machines to the rest of the components of the architecture 200.

The events that are sent to the launcher 303 instead of being sent tothe current front application allow the launcher 303 to make decisionson which application(s) are to be running at the any moment in time andbeing configured to force applications to exit means that the launcher303 can enforce which applications are to be currently running. Thelauncher 303 is also required to inform the event manager 301 when it isstarting and stopping applications.

FIG. 36 is a flow diagram, showing an overview of the method 3700performed by the launcher 303. The method 3700 can be executed by theCPU 205 for computer implementations. Alternatively, the method 3700 canbe executed by the CPU 4305 in set top box implementations or by the CPUof a remote server. The method 3700 begins at the first step 3701, wherethe launcher 303 connects to the event manager 301, and then continuesto a next step 3702 where persistent applications are started. At thenext step 3703, the launcher 303 waits for an event and when an event isreceived the launcher 303 proceeds to step 3705. If the event is theNO_CARD identifier at step 3705, then the process proceeds to step 3707.Otherwise the method 3700 proceeds to step 3709. At step 3707, thelauncher 303 performs a predetermined system specific function (e.g.displays a message on the display 101) in response to the NO_CARDidentifier and the method 3700 returns to step 3703.

If the event at decision step 3705 is determined not to be a NO_CARDidentifier, another decision step 3709 is entered to determine whetheror not the event is a PRESS, RELEASE, REMOVE or MOVE. If this decisionstep 3709 returns a “yes”, that is, the event is one of theaforementioned events, then the method 3700 proceeds to step 3800.Otherwise the method 3700 proceeds to a further decision step 3713. Atstep 3800, the launcher 303 changes the application in accordance withthe process steps described with reference to the flow diagram FIG. 37.The method 3700 returns to step 3703.

If the event at step 3709 is not one of the PRESS, RELEASE, REMOVE orMOVE events, then a decision step 3713 is entered. This decision step3713 makes a determination on a BADCARD or LOW_BATT event. If the eventis a BADCARD or LOW_BATT event at step 3713, then the method 3700proceeds to step 3715, otherwise the method 3700 proceeds to step 3717.At step 3715, the launcher 303 gives the user feedback on the event thathas occurred (e.g. displaying a “Low Battery” message on the display 101if the LOW_BATT event is determined or a “incorrect Card” upondetermination of a BADCARD event) and the method 3700 returns to step3703. If the event at decision step 3713 is neither a BADCARD orLOW_BATT event, then step 3717 is entered.

If the event is an APP_REGISTER event at step 3717, then the method 3700proceeds to step 3900, “Application Registering”. Otherwise the method3700 proceeds to step 3725. At step 3900, the application is registeredas described herein with reference to FIG. 38 (i.e. the applicationinforms the other components 301, 302 and 306 that it is now ready toreceive messages, as described above with reference to section 8.3.4)and the method 3700 returns to step 3703. A method of registering anapplication in accordance with step 3900, will be described in moredetail below with reference to the flow diagram of FIG. 38. At step3725, the event is discarded and the method 3700 returns to step 3703.

FIG. 37 is a flow diagram showing the method 3800 of changing anapplication, which is performed by the launcher 303. The method 3800 canbe executed by the CPU 205 for computer implementations. Alternatively,the method 3800 can be executed by the CPU 4305 in set top boximplementations or by the CPU of a remote server. The method 3800 beginsat step 3817, where if a REMOVE message has been received by thelauncher 303 then the process proceeds directly to step 3813. Otherwise,the method 3800 continues to decision step 3801. At decision step 3801,if the service represented by the event is associated with anapplication that is registered, then the method 3800 proceeds directlyto step 3819. Otherwise, the method 3800 continues to step 3803, where aservice identifier lookup is performed to determine the location and/orname of a new application and any initial data associated with the newapplication. For example, the initial data may be a URL to load into abrowser 403 or a media file to be loaded into a media playerapplication. At the next step 3805, if the application is alreadyrunning the method 3800 proceeds to step 3819. Otherwise, the method3800 proceeds to step 3809, where the new application is retrieved fromapplications 304. At the next step 3811, the new application is startedas the front application, and at step 3812 the event manager 301 isnotified of the component identifier (Xid) of this new frontapplication.

Decision step 3819 is entered either from step 3801 if the servicerepresented by the event is associated with an application that isregistered or if the application is already running. At step 3819, if itis determined that an INSERT message is received by the launcher 303,then the method 3800 concludes. Otherwise, the method 3800 proceeds tostep 3807, where the new application is sent a GAINING_FOCUS eventindicating that the new application will soon be changing state. Afterthe new application is sent a GAINING_FOCUS event, or as a result of aREMOVE event detected at decision step 3817, control is passed todecision step 3813. At step 3813 it is determined if there is anexisting front application, if there is no previously front application,then method 3800 concludes. Otherwise, a LOSING_FOCUS event is sent tothe previous front application enabling the previous front applicationto complete immediate tasks, before the method 3800 concludes.

FIG. 38 is a flow diagram showing the method or process 3900 ofregistering a new application, which is performed by the launcher 303.The method 3900 can be executed by the CPU 205 for computerimplementations. Alternatively, the method 3900 can be executed by theCPU 4305 in set top box implementations, or by the CPU of a remoteserver. The process 3900 begins at step 3901, where a new service grouplist, including the application, referred to with reference to step 3900of FIG. 36, is generated. At the next step 3903, a GAINING_FOCUS eventis sent to this application. Then at the step 3905, if any applicationsare not part of the new service group and are not persistent, the method3900 proceeds to step 3907. Otherwise the method 3900 concludes. At step3907, any applications which are not part of the service group are sentan EXIT_NOW event, and the method 3900 proceeds to a next step 3908where the event manager 301 is notified that the applications, whichwere not part of the new service group, have been terminated. The method3900 then concludes.

FIG. 39 is a flow diagram showing the process steps 4000 performed by anapplication when receiving events from the launcher 303. The method 4000can be executed by the CPU 205 for computer implementations.Alternatively, the method 4000 can be executed by the CPU 4305 in settop box implementations or by the CPU of a remote server. The methodsteps 4000 begins at step 4001, where the launcher 303 connects to theevent manager 301 and then the method 4000 proceeds to step 4002. Atstep 4002, the application is registered by sending an APP_REGISTERmessage to the launcher 303. Following the flowchart shown in FIG. 39,to the next step 4003, the application waits for events and when anevent is received the process proceeds to step 4005. If the event is aGAINING_FOCUS event at step 4005, then the method 4000 proceeds to step4007. Otherwise the method 4000 proceeds to step 4009. At step 4007, theapplication is initialised if necessary, optionally using thedistinguishing identifier and optionally using the data field of theGAINING_FOCUS event. This data field used for initialisation may includea URL to load, a filename to load, etc. Control returns to waiting forevents at step 4003.

If the event is a PRESS, RELEASE or MOVE event at step 4009, then themethod 4000 proceeds to step 4011. Otherwise the method 4000 proceeds tostep 4013. At step 4011, an application specific action is performed inresponse to the event. The application specific action is performedusing data from the event (i.e. data associated with an indicium on thecard 10, (eg URL, character or video name)), the X/Y position ordistinguishing identifier or any combination of these.

The application specific action is typically associated with an indiciumon the card 10. For example, an indicium can be associated with aparticular URL and when the indicium is pressed the URL may be accessed.Therefore, for example, the computer 100 or STB 601 can download desiredprograms from a Web Page that was designated by the URL, and a card usercan receive the service (i.e program download) from the system 600.Further, an indicium can be associated with a particular memory addressand when the indicium is pressed the memory address can be used to datastore at the memory address. Therefore, for example, the computer 100 orSTB 601 can download desired image data from memory or from a fileserver on a network, which was designated by the memory address, and acard 10 user can receive the service (e.g. image data download) from thesystem 600. After step 4011, the method 4000 returns to step 4003 asshown in FIG. 39.

The process steps 4000, according to the flowchart of FIG. 39 asdescribed above, filters through to step 4013 if an event is notdetermined to be any one of a GAINING_FOCUS, PRESS, RELEASE or MOVEevent at the corresponding decision steps 4005 or 4009. If the event isa LOSING_FOCUS event then at step 4013 the method 4000 proceeds to step4015. Otherwise the method 4000 proceeds to decision step 4017. At step4015, the application reverts to an inactive state and the method 4000returns to step 4003. If the event is an EXIT_NOW event at step 4017,then the method 4000 concludes. Otherwise the method 4000 proceeds tostep 4019, where the event is ignored and the method 4000 returns tostep 4003.

FIG. 40 is a flow diagram showing the method 4100 performed by thebrowser controller 402 application when receiving events from thelauncher 303. The method 4100 can be executed by the CPU 205 forcomputer implementations. Alternatively, the method 4100 can be executedby the CPU 4305 in set top box implementations, or by the CPU of aremote server. The method 4100 begins at step 4101, where the browserapplication sends an APP_REGISTER message to the launcher 303. At thenext step 4103, the browser application waits for events and when anevent is received the method 4100 proceeds to step 4105. If the event isa GAINING_FOCUS event at step 4105, then the method 4100 proceeds tostep 4107. Otherwise the method 4100 proceeds to step 4109. At step4107, the application is initialised if necessary. For example, theapplication reads the data field of the GAINING_FOCUS message and, ifthe data field represents a URL, the application loads that URL.Initialisation is performed on the browser controller 402, by loading aninitial URL into the browser application 403 and storing the base of theURL. The method 4100 continues at the next step 4121, where thedistinguishing identifier is determined from the event At the next step4123, a JavaScript call back function (preferably known as theNotify_Card_ID) is called in the current top-level document with thedistinguishing identifier 1110 as the argument, and then the method 4100returns to step 4103.

If the event is a PRESS, RELEASE or MOVE event at step 4109, then themethod 4100 proceeds to step 4200. Otherwise the method 4100 proceeds tostep 4113. At step 4200, a browser application specific action isperformed in response to the event. The browser application specificaction will be described in more detail below with reference to the flowdiagram of FIG. 41. After step 4200, the method 4100 returns to step4103.

If the event is a LOSING_FOCUS event at step 4113, then the method 4100proceeds to step 4115. Otherwise the method 4100 proceeds to step 4117.At step 4115, the browser application reverts to an inactive state andthe method 4100 returns to step 4103.

If the event is an EXIT_NOW event at step 4117, then the method 4100concludes. Otherwise the method 4100 proceeds to step 4119. At step4119, the event is ignored and the method 4100 returns to step 4103.

FIG. 41 is a flow diagram showing a browser application method 4200executing on the system 600 incorporating the software architecture 200.The method 4200 can be executed by the CPU 205 for computerimplementations. Alternatively, the method 4200 can be executed by theCPU 4305 in set top box implementations or by the CPU of a remoteserver. The method 4200 begins at step 4201, where if the event is aPRESS event then the method 4200 proceeds to step 4225. Otherwise themethod 4200 proceeds to step 4203, where the event is ignored and themethod 4200 concludes. At step 4225, the distinguishing identifier isdetermined from the event At the next step 4227, if the current page hasbeen notified about the current distinguishing identifier then themethod 4200 proceeds to step 4205. Otherwise, the method 4200 proceedsto step 4229, where the JavaScript call back function known as theNotify_Card_ID is called in the current top-level document with thedistinguishing identifier as the argument, and then the method 4200proceeds to step 4205.

At step 4205, data is retrieved from the event. At the next step 4207,if the data is a single character then the method 4200 proceeds to step4209. Otherwise the method 4200 proceeds to step 4211. At step 4209, thecharacter is sent to the browser application 403, and the method 4200concludes. This may be used to provide the same effect as a userpressing a key on a keyboard or a button on a conventional remotecontrol. The current page may provide an action which is performed onreceipt of a given keypress using existing methods such as thoseprovided by Hyper Text Mark-up Language (HTML).

If the data starts with “js:” at step 4211, then the method 4200proceeds to step 4213. Otherwise the method 4200 proceeds to step 4215.At step 4213, a JavaScript function in the current top-level document iscalled and the method 4200 concludes. The specified data may optionallyinclude an argument for the JavaScript function. For example, the data“js:hello” would indicate that the browser controller is to call theJavaScript function “hello”, and the data “js:hello(world)” wouldindicate that the browser controller is to call the JavaScript function“hello” with the argument “world”.

If the data starts with “cmd:” at step 4215, then the method 4200proceeds to step 4217. Otherwise the method 4200 proceeds to step 4219.At step 4217, a specified browser function is called and the method 4200concludes. For example, the data “print” would result in the browsercontroller instructing the data “back” would result in the browsercontroller-instructing the browser to return to the previously displayedpage.

If the data is an absolute URL at step 4219, then the method 4200proceeds to step 4221. Otherwise the method 4200 proceeds to step 4223.At step 4221, the data is loaded into the browser application 403 as aURL and the method 4200 concludes.

At step 4223, the data is loaded into the browser application 403 as aURL after the base URL has been appended, and the method 4200 concludes.

A variation on the browser controller application described above withreference to FIG. 40, is a program controller, which provides control ofa software program. The software program can include any program, whichis normally controlled with one or more keypress events (e.g. like akeyboard keypress event or the equivalent on a game controller). Theprogram controller can be used to provide card-based control of anexisting software program such as an interactive game. The programcontroller process behaves substantially as described with reference toFIG. 40 with the following exceptions. If the event at step 4105 is aGAINING_FOCUS event, then the program controller process proceeds to astep of getting a Resource Locator, for the software program to becontrolled, from the GAINING_FOCUS message. The process then proceeds toa step of getting and starting the software program specified by theresource locator. The program controller process then proceeds to step4103. Further, at step 4109, instead of testing for a PRESS, RELEASE orMOVE event, this particular variation in the method 4100 wouldsubstantially check for a PRESS event If the event is a PRESS event, theprocess proceeds to the steps of getting the data from the event, takingthe first character from that data, and effecting a keypress of thatcharacter resulting in the same effect as if a user had typed thatcharacter on a keyboard.

10.1 Special Routing Rules for the Launcher

The launcher 303 has a special set of routing rules and the launcher 303always receives the following events:

-   -   EM_REMOTE_INSERT    -   EM_REMOTE_REMOVE    -   EM_REMOTE_BADCARD

The launcher also receives EM_REMOTE_PRESS, EM_REMOTE_RELEASE andEM_REMOTE_MOVE messages if a service identifier does not match acurrently front application or if the distinguishing identifierrepresents the NO_CARD present identifier (i.e. all zeroes). For thepurposes of determining whether or not messages match, theservice-specific identifier is ignored.

The launcher 303 can be configured to explicitly make itself the frontapplication by sending itself a EM_GAINING_FOCUS event. In thisinstance, all messages will be sent to the launcher 303 regardless ofthe service identifier of the message. The launcher 303 is not requiredby the protocol to respond to any of these messages.

10.2 Sample Implementations

This section outlines several examples of launcher configuration.

10.2.1 Generic Launcher

A generic launcher can be used in an open set-top-box or computerenvironment with broad-band Internet connectivity. In accordance withthis configuration, the launcher 303 assumes that there are applicationsthat can be downloaded to a local machine or designated remote machineand run. A generic launcher can also be configured to accommodate theuse of applications that use the browser 403 via the browser controller402.

The generic launcher can be configured to download applications as wellas support persistent applications. The computer 100 running the system600 preferably has a reasonably fast Internet connection available. Inthis instance, some of the applications 304 can be web pages withJavaScript that is handled by a persistent application called thebrowser controller 402, as described above. Further some of theapplications 304 can be designed to work together. The generic launcherpreferably also assumes that the communications link used by the remotereader 1 is unreliable (i.e. an IR link) so messages can be lost.

10.2.2 Rules for the Generic Launcher

The following rules are the rules that are preferably used by thelauncher 303 to define the system 600.

-   -   EM_REMOTE_PRESS and EM_REMOTE_RELEASE events that have the        NO_CARD present identifier (i.e. all zeroes) are used as a cue        that the user wishes to exit from the front application. This        could result in the system 600 either generating a “please        insert a card” message on the display 101 or returning to an        earlier application, depending on the configuration of the        system 600.    -   EM_REMOTE_BADCARD events cause the launcher 303 to provide the        users with feedback indicating that the card is faulty.    -   EM_REMOTE_INSERT, EM_REMOTE_REMOVE are not relied upon to        provide the bounds of the session because of the assumed        unreliable communications method from the remote reader 1 to the        event manager 301.    -   If the launcher 303 receives an EM_REMOTE_PRESS,        EM_REMOTE_RELEASE or an EM_REMOTE_MOVE message then the launcher        303 does a service mapping, and if the service identifier        resolves to a downloadable application then the corresponding        application is downloaded and run. The mapping is done by        querying the Directory Server 305 with the service information        from cards. The values returned from the Directory Server 305        are an application location and associated service data. The        application location specifies the location of the application        or a value the launcher recognises as a local application. The        service data is the initialisation data that is sent to the        application in the EM_GAINING_FOCUS message. If the application        location is empty the launcher 303 is configured to decide which        application to use based upon the service data which will be a        URL.    -   When a new application registers with an EM_APP_REGISTER message        the specified service groups are compared with a currently        running set of applications and if there is no overlap then all        other currently running applications are told to exit. The new        application is made the current front application (using an        EM_GAINING_FOCUS event) and the previously front application is        sent an EM_LOSING_FOCUS event. If this occurs and the service        identifier resolves to a web page then the focus is changed,        using an EM_GAINING_FOCUS message, to the browser controller 402        with the address (location) of the web page in the data field.        The data field is returned in the query that told the launcher        303 that the service identifier resolved to that web page. In        this situation, an EM_LOSING_FOCUS event is also sent to the        current front application. All other applications are told to        exit.        10.3 An Example Single Use System

The architecture 200 can be configured for use with a single specialisedapplication. In this instance, the launcher 303 can be used where it isadvantageous to have a physical token (e.g. a bank card) where part orall of the user interface can be printed onto the token. The exampledescribed below is in the form of an automatic teller machine, andwhilst this example is described in terms of a specific specialisedapplication it should not be read as being limited to automatic tellermachines. Such a system can be configured to be able to use a single orat least very limited number of cards. In this system no otherapplications 304 are started regardless of the card that is entered. Thelauncher 303 takes the role of a single application 304 as well as thatof a system controller. No modifications are made to the event manager301.

A single use system can be used in an automatic teller machine forexample. A bank can produce personalised bank cards with commonly usedoptions on the cards that are used as the sole or supplementaryinterface for an automatic teller machine. In this instance, theautomatic teller machine preferably contains an event manager 301 andother core process components of the architecture 200. In this specificexample the communications link between the remote reader 1 and theevent manager 301 must also be reliable.

10.3.1 Rules

The following rules can be used by a launcher 303 to define a single usesystem bank teller machine example:

-   -   Any events that do not come from cards associated with a        participating bank could cause the launcher to display an        incompatible card screen on the terminal.    -   EM_REMOTE_BADCARD events are ignored.    -   EM_REMOTE_INSERT events are used to start the transaction.    -   EM_REMOTE_REMOVE events are used to end the transaction.    -   EM_REMOTE_PRESS, EM_REMOTE_RELEASE and EM_REMOTE_MOVE events are        treated as a user interaction. These are preferably handled        directly by a launcher as that is the one application that is        running.    -   Service mappings to an external Directory Server are never done.        If the card is not one that a particular automatic teller        machine (ATM) knows about then the card should be rejected.        These rules are examples of how a single use system can be        configured to provide a specific application in the form of an        ATM.        10.4 Directory Service Operation

FIG. 58 is a flow diagram, showing an overview of the process 5800performed by the Directory Service 311. The process 5800 is executed bythe CPU 205 of a computer 100, which performs the role of a DirectoryService 311. The software program as shown in FIG. 58 is stored in amemory medium such as Memory206 or CD-ROM212 in the system 600A orMemory 4306 in the system 600B. The process 5800 begins at the firststep 5801, where the Directory Service 311 is started. At the next step5802, the CPU waits for incoming events from a Launcher 303. The eventsare sent from Read Device 1 to Launcher 303 via Event Manager 301. Atthe next step 5803, the CPU receives a request from a Launcher 303,which contains a Distinguishing identifier, which is to be mapped by theDirectory Service 311. The connection between the Launcher 303 and theDirectory Service 311 is shown in FIG. 8.

At the next step 5804, the CPU searches a directory-mapping table tocheck if the table has an entry corresponding to the Distinguishingidentifier. The directory-mapping table typically contains relationsbetween Service identifiers and corresponding application location (e.g.URL) and service data and additionally contains relations betweenDistinguishing identifiers and the corresponding application locationand service data. Typically, the relation involving the Serviceidentifier is used with respect to cards 10 for which the DirectoryService 311 is intended to maintain service-level information for allcards 10 which can be used for that service (for example, the locationof the application 304 which is to be executed to provide the servicefor the card 10). Typically, the relation involving the Distinguishingidentifier is used with respect to cards 10 for which the DirectoryService 311 is intended to maintain information specific to the actualcards 10 or groups of cards 10 which have identical service-specificidentifiers (for example, the location of a media file which is to beplayed to provide the service for the card 10). The directory-mappingtable is typically stored in hard disk 210 or in memory 206. At step5804, if there is an entry for the Distinguishing identifier in thedirectory mapping table, at the next step 5805, the CPU retrieves theapplication location and service data from this entry and moves to step5806. At step 5804, if there is not an entry for the Distinguishingidentifier in the table, the CPU at step 5808 extracts the Serviceidentifier from the Distinguishing identifier by taking the relevantportion of this value (typically the first 5 bytes as is indicated inFIG. 11). At the next step 5809, the CPU searches the directory-mappingtable for an entry corresponding to the Service identifier. If one isfound, the CPU retrieves the application location and service data fromthis entry at the next step 5810 and moves to step 5806. If one is notfound, at step 5811, an entry is placed in a log file indicating that arequest had been made for the specific Distinguishing identifier and, atstep 5812, an error is returned to the Launcher 303 indicating that theService identifier part of the Distinguishing identifier supplied is notknown by this Directory Service 311. The flow then continues to step5802.

At step 5806, where a Distinguishing identifier or a Service identifierhas been successfully found, the Distinguishing identifier andcorresponding application location and service data is written to a logfile and the CPU returns the application location and service data tothe Launcher 303 which made the request. Flow then continues to step5802 to wait for another event.

11. General

Typically, applications 304 are resident on the hard disk drive 210 andread and controlled in their execution by the CPU 205. Intermediatestorage of programs and any data fetched from the network 220 can beaccomplished using the semiconductor memory 206, possibly in concertwith the hard disk drive 210. In some instances, the applications 304will be supplied to the user encoded on a CD-ROM or floppy disk and readvia the corresponding drive 212 or 211, or alternatively may be readfrom the network 220 via the modem device 216. Other mechanisms forloading software application into a computer system 100 from othercomputer readable medium include magnetic tape, a ROM or integratedcircuit, a magneto-optical disk, a radio or infra-red transmissionchannel between the computer module 102 and another device, a computerreadable card such as a smart card, a computer PCMCIA card, and theInternet and/or Intranets including email transmissions and informationrecorded on Websites and the like. The foregoing is merely exemplary ofrelevant computer readable media. Other computer readable media are alsopossible including combinations of those described above.

Alternatively, the process components 301 to 306 described above can beimplemented in dedicated hardware as one or more integrated circuitsperforming the described functions or sub-functions. Such dedicatedhardware may include graphic CPUs, digital signal CPUs, or one or moremicroCPUs and associated memories. An examples of dedicated hardware isthe set top box 601 for a television described with reference to FIG. 6(b) above.

12. Other Variations

12.1 A Session Identifier

As described above, the distinguishing identifier is included in everyINSERT, REMOVE, PRESS, RELEASE and MOVE message sent from the reader 1to the computer 100 or set-top box 601. As an alternatively, thedistinguishing identifier can be sent in connection with an INSERTmessage only. In this instance, upon insertion of a new card 10, thereader 1 generates a session identifier (not illustrated). The sessionidentifier identifies a current session of a card insertion. The sessionidentifier, for example, can be a pseudo-random number (which can berepresented with 2 bytes of data) or the session identifier can be anumber that is incremented each time a card is inserted (and reset tozero when a predetermined value is reached). The reader 1 sends anINSERT message to the computer 100 or the set-top box 601, whichincludes a distinguishing identifier as previously described above and asession identifier which is generated for each new insertion. Allsubsequent PRESS, RELEASE and MOVE messages need not include thedistinguishing identifier but will include the session identifier anduser interface object data or press coordinates previously described.

When using a session identifier, the system 600 performs as describedabove with reference to FIGS. 6( a) and 6(b), except that the eventmanager 301, upon receiving an INSERT message from a reader 1, storesthe session identifier as the current session identifier and adistinguishing identifier as the current distinguishing identifier. Whenthe event manager 301 receives a PRESS, RELEASE or MOVE message, theevent manager 301 checks that the session identifier is equal to thecurrent session identifier. If so, the event manager 301 sets adistinguishing identifier used in all messages to the currentdistinguishing identifier. Otherwise, if the session identifier is notequal to the current session identifier, the event manager 301 informsthe user, via the display manager 306, and the display device 101, thata message has been received without a corresponding INSERT message. Theuser, for example, is then requested to remove and reinsert the card 10.

12.2 Other Characteristics of a User Press

As described above, the sending of information relates to the pressing,moving and releasing of an object (typically with a finger or stylus) onthe touch panel 8 of the reader 1. However, the reader 1 can sendadditional information pertaining to an interaction from the touch panel8 to the computer 100 or set-top box 601 for use by the system 600. Forexample, the additional information can represent a length of time or anamount of pressure exerted upon the touch panel 8 as a result of apress. This additional information can be incorporated in the PRESSmessages sent from the reader 1 to the system 600 and with theEM_READER_PRESS messages sent within the system 600. In this instance,the information is passed to an application 304 corresponding to thecard inserted in the reader 1. An application can make use of theadditional information to provide, for example, an added effect on aparticular action. For example, the application can use pressureinformation, when associated with a press on an indicium indicating anincrease in (audio) volume, to determine an amount of increase involume. That is, the harder the press on the selected indicium, thehigher the rate of increase in the volume and conversely, the softer thepress on the selected indicia the lower the rate of increase.

Another example of the use of additional information in relation to alength of time (or duration) of an interaction with a touch panel 8 isdescribed below. If a press is of very short duration, the press can tobe considered to be a “tap”. On the other hand, a press of very longduration can be considered as a persistent “holding down” of a keypress.In this instance, additional information can add an extra dimension to amode of interacting with an instant software application. For instance,a “tap” on the touch panel 8 can be an instruction to the softwareapplication to select an item displayed at a current (on-screen) cursorposition.

12.3 No Coordinates

A PRESS and RELEASE message can be configured not to include coordinatedata of a user's interaction with the touch panel 8. In this instance,coordinate data is only sent from the reader 1 to the system 600 inconjunction with a MOVE message. The advantage of not includingcoordinate data in a PRESS and RELEASE message is a size reduction ofmessages sent by a reader 1 to the system 600, where an applications 304does not require coordinate information for mapping from coordinates touser interface element data.

12.4 Two-way Protocol

A one-way or a two-way protocol can be used for communication between areader 1 and a computer 100 or set-top box 601. The description of thereader 1 hardware with reference to FIG. 10, and the I/O Daemondescribed with reference to FIGS. 8 and 9 included a sending ofinformation from a reader 1 to computer 100 or set-top box 601 and viceversa. The sending of information back to a reader 1 from a computer 100or set top box 601 can be used to change the data stored on a card 10.For example, changing user interface object data stored on the memorychip of a smart card 10.

A two-way protocol can also be used to enable hand-shaking in theprotocol. For example, a two-way protocol between a reader 1 and aset-top box 601 or computer 100 can be used so that the system 600 canacknowledge the receipt of an INSERT message sent when a card isinserted in the reader 1. A system 600 which supports a two-way protocolshould also provide an additional message in the event manager protocol,in order to allow an application to send a request in order to modify aportion of the stored data on a card 10, sent to the I/O daemon 300 viathe event manager 301. The I/O daemon 300 can then send a message to thereader 1 to bring about a requested action. For example, if the system600 uses a two-way protocol then the system 600 can provide a securitymechanism to ensure that applications can not modify cards without thepermission of a user or without a system-defined privilege. In oneexample of such a system, the event manager 301 can present a displayedmessage to a user asking if it is OK for the application to modify acurrently inserted card. The user can assent to the proposal by pressinga first region of the touch panel 8 and dissent to the proposal bypressing a second region of the touch panel 8. If the user assents tothe modification of the card 10 then the event manager 301 can allow therequest from the application 304 to be passed onto the I/O daemon 300and then on to the reader 1. On the other hand, if the user dissentsfrom the modification, the event manager 301 drops the message and theinformation is not sent to the reader 1.

12.5 Alternative Read Device

In the above system 600A and 600B, the Read device 1 has a substantiallytransparent touch sensitive membrane arranged to overlay the card 10. Toreduce a cost of the Read Device 1, instead of the touch sensitivemembrane, the Read Device 1 may has a plurality of user operableswitches positioned around the receptacle into which the smart card 10is insertable for reading the data, the distinguishing identifier andrelation information to associate the data with each switch. Thereforethe user can select at least one of the switches that correspond to atleast one indicia on the card, since the operable ones of the switchesare associated with indicia on the smart card visually. In this caseCPU45 reads the data corresponding to a switch pressed by the user basedon the relation information and the distinguishing identifier from thecard 10 and sends them to Event Manager 301.

13.0 Alternative Software Architecture

A further software architecture 4900 for the hardware architecturedepicted by the system 600, is generally illustrated in FIG. 48 andrepresents an alternate software architecture to that described inprevious sections. The alternative architecture 4900 is configured to bescaled from very low hardware requirements at the users home (ie. asimple set-top box), up to a powerful home system, where for example theset-top box 601 functionality is implemented on personal computingsystem. Further, the alternative architecture 4900 is preferablyimplemented within the hardware system 600.

13.1 Structure

The architecture 4900 is divided into six distinct processes and oneclass of process. The distinct processes include a smart card interface4902, referred to as an I/O daemon as in the architecture 200, an eventmanager 4904, a display manager 4906, a master launcher 4908, an(application) launcher 4910 and a directory service 4912. The class ofprocess is formed by one or more smart card applications 4920. In thearchitecture 4900 there exists one card daemon 4902, one event manager4904, one display manager 4906 and one launcher 4910 for every smartcard remote connection, usually formed by the set-top box 601, but onlyone master launcher 4908 for each computer that is running the launchers4910, and at least one directory service 4912 for all systems.

In this form, the architecture 4900 can be physically separated intothree distinct parts 4914, 4915 and 4916, as shown by the dashed linesin FIG. 48, each of which can be run on physically separate computingdevices. Communication between each of the parts of the system isperformed using TCP/IP streams as with the architecture 200.

The I/O daemon 4902 is a process that converts datagrams received fromthe smart card remote reader 1 into a TCP/IP stream The I/O daemon 4902is not intended to understand the data format used by the reader 1, butto operate independent of any changes in the smart card remote dataformat, and thus provides the capability to work with multiple versionsof the reader 1.

The I/O daemon 4902 is started when the user starts the system 600which, in the case of the set-top box system 600B, is when the set-topbox 601 is turned on. For the computer system 600A, the I/O daemon 4902may be started when the user starts the smart card system after theevent manager 4904 and master launcher 4908 have been started.

The event manager 4904 forms a central part of the architecture 4900 inthat all communications are routed through the event manager 4904. Theevent manager 4904 is responsible for gathering all events that aregenerated by the smart card remote reader 1 and relayed by the I/Odaemon 4902. These events are then redistributed to the variousprocesses and running applications.

A further role of the event manager 4904 is to isolate misbehavingapplications from other well-behaved applications. In this regard, anyevents passed through the event manager 4904 are guaranteed to becorrect to the extent that the event manager 4904 can check the event.The event manager 4904 is required to check that an event has a validheader and the correct data length, but is typically not configured tocheck if the data is in the correct format.

Any changes to the protocol between different versions are also to bedealt with by the event manager 4904. If possible, the events are to berewritten to conform with the version of the data format that theoperating application 4920 understands. If such is not possible, thenthe event manager 4904 reports an error to the originating application4920. When different data format versions are being used, the eventmanager 4904 ensures that the smallest disruption possible occurs.

The display manager 4906 operates in concert with those applications4920 operating to control which operating application 4920 has prioritywith respect to the particular output device 116, typically a display(e.g. 116). It is the role of the display manager 4906 to select whichvideo stream is sent to the display 116, this information being obtainedfrom the respective launcher 4910 of the application 4920, via the eventmanager 4904. Generally only the front (ie. foreground) application willproduce a video display stream. Further, the display manager 4906 mayoperate to maintain a constant output stream from the inconsistent inputstreams and may fill-in some parts of the output stream withextrapolated data.

The event manager 4904 is not responsible for deciding when anapplication 4920 needs to be started/ended or for actually starting orterminating an application 4920. These operations are both theresponsibility of the launchers 4908 and 4910, to be discussed below.Moreover, the event manager 4904 does not have any presence on the usersscreen or other output device 116. Any system related feedback, such asthe display of the initial insert of a smart card, is performed by thelauncher 4910.

For the system 600B of FIG. 6( b) incorporating the alternativearchitecture 4900, there will typically be an event manager 4904 runningfor every set-top box 601 that is allowed to connect to the system 600B.For the system 600A incorporating the architecture 4900, the eventmanager 4904 will be started when the smart card system 600A, is startedafter the master launcher 4908 has been started.

The role of the master launcher 4908 is to start the launchers 4910 atthe request of any of the event managers 4904. When the I/O daemon 4902connects to the event manager 4904, the event manager 4904 requests themaster launcher 4908 to start a first process for the event manager4904. This first process will generally be a launcher 4910 for any smartcard application 4920. The master launcher 4908 is also responsible forshutting down the launcher 4910 of an application 4920 when the eventmanager 4904 so requests, and for informing the event manager 4904 thatthe correct launcher 4910 has exited.

For the system 600B of FIG. 6( b) incorporating the alternativearchitecture 4900, there will always be one master launcher 4908 runningfor each physically separate server 150, 152 running smart cardapplications 4920. This one master launcher 4908 handles the requestsfor all event managers 4904 that request launchers 4910 on that server.For the system 600A, the master launcher 4908 commences operation eitherbefore or no later than at the same time as the rest of the smart cardsystem.

The card directory service 4912 is provided to translatevendor-application value (Service identifier value) stored within smartcards 10 into an application location such as Uniform Resource Locators(URLs) that each point to the application 4920 associated with avendor-application pair (Service identifier) which will be described.The directory service 4912 can be split into a number of parts bychanging the launcher 4910 so that applications 4920 can run on separatesystems to the launcher 4910. The directory service 4912 performs thisfunction using a distributed look-up system where the query is passed onto another directory server if the directory service currently inpossession of the query does not know the answer. Such a distributedsystem allows each directory server to have a limited knowledge of thetransition from vendor-application ID pairs to URL's, but to still beable to translate all ID's to URL's. This provides a number ofadvantages including a simpler database at each directory, is morerobust and permits servers to become inoperable (i.e. crash or beremoved from service) whilst still permitting queries.

Referring to FIG. 52, the control template customisation informationthat distinguishes the smart card 10 from traditional smart cardsincludes a tuple of data from by a vendor identifier, a card identifierand an application identifier. The vendor identifier and the applicationidentifier pair are equivalent to the service identifier described abovefor the architecture 200. Also, the card identifier is equivalent to theservice-specific identifier described above for the architecture 200.Further, associated with each of the icons 4804 is corresponding datathat, when a user presses on the touch panel over the icon 4804, is sentas event data that, when passed to the particular application 4920,implements a particular operation within that application. Furtherdetection of user actions may be incorporated, for example to detect therelease of an icon, as distinct from a depression of that icon, and alsoto detect moving depression, where the user may scribe a finger acrossthe touch panel 8 to perform a particular function. On each such action,event data stored on the card can be sent, which may be read from adifferent location of memory on the card in each case. The serviceidentifier implemented in this alternative architecture 4900 as avendor-application identifier pair allows the vendor, of an applicationassociated with a smart card, to be distinguished from other. Fordeployments of the architecture 4900 where there is no need todistinguish a vendor of the application associated with the smart card,the vendor identifier and the application identifier can be treated as asingle value: a service identifier.

The first process started by the insertion of a smart card 10 into areader 1 will be, in a generalised system (e.g. home), a launcher 4910.In specific systems, specific applications may be commenced. For examplea banking teller would start a banking application. Another exampleincludes the use of restricted launchers that only start a specifiedsub-set of applications. The launcher 4910 is a smart card applicationthat starts other applications 4920 for a specific one event manager4904. It is the decision of the launcher 4910 to start and endapplications 4920 and to actually start and terminate applications 4920.The launcher 4910 informs the event manager 4904 when applications 4920are starting and ending, and tells applications 4920 that they arereceiving or losing focus, or when they need to exit In this regard,where a number of applications 4920 are operating simultaneously, theapplication that is currently on-screen is the application having focus.When another application is about to take precedence, the launcher 4910tells the current application that it is losing focus, thereby enablingthe current application to complete its immediate tasks, and tells thenew application it is gaining focus, and that the new application shallsoon be changing state. The launcher 4910 must be able to force aprogram to exit.

The first application 4920 started (ie. usually the launcher 4910) isgiven special privileges, and receives “NO_CARD”, “Bad_CARD” and“POWER_OFF” events generated from the remote reader 1. The firstapplication 4920 also receives events that are intended for applications4920 that are not the current front application, and the launcher 4910operates to correctly interpret these events. Such is related to thespecific applications mentioned above, so that the launcher correctlyinterprets any changes. The launcher 4910 is an application 4920 buthaving special rights, including the right to start and shut down otherapplications.

The launcher 4910 is preferably only started when the event manager 4904requests the launcher 4910 to be started. The launcher 4910 can also betold to exit by the event manager 4904.

Applications are started by the launcher 4910 either as a response tothe first user selection on a corresponding smart card 10, or at therequest of another one of the application 4920. In this regard, thearchitecture 4900 provides a substantial enhancement over conventionalarrangements through each application 4920 being organised during itsprogramming, as a member of one or more application service groups.

13.2 Application Service Groups

An application service group is comprised of a number of smart cardapplications 4920 that act co-operatively, as opposed to merelysimultaneously, to provide a particular set of functions. Applications4920 that form part of a service group are permitted to runsimultaneously, and also share a communication means (ie. the eventmanager 4904) by which data may be exchanged. Each such application 4920is a process or sub-process that provides a set of functionscorresponding to a particular user interface or set of user interfaces.Such an application 4920 may or may not have a visible display.

With reference to the example represented in FIG. 49, a service group isinitiated once an application 4920 that forms part of that service groupis started and registers the particular service group with the eventmanager 4904. As seen in FIG. 49, a first application 4926 hasassociated therewith two smart cards 4924 and 4926, and a secondapplication 4934 is operable with smart cards 4928, 4930 and 4932.Accordingly, upon insertion of the card 4922 into the reader 1, the carddaemon 4902 communicates that occurrence with the event manager 4904which, via the launcher 4910 commences application 4926. Thecommencement of the application 4926 enables a service group 4936, thisgroup also including application 4934. Applications that correspond tothe currently established service group may be started by inserting therelevant smart cards. For example, removal of the card 4922 andinsertion of the card 4932 operates to launch application 4934,maintaining the service group 4936 as being active. Further, thestarting of applications that form part of the same service group doesnot cause other applications from the same service group to terminate.Rather, the other applications are kept running in the background.

Termination of a service group is initiated either by touching on anempty remote reader 1, or by inserting a smart card corresponding to adifferent service group, such as the card 4938, corresponding toapplication 4940 in service group 4942. Termination of a service groupcauses all the applications that are currently running as part of thatservice group to be similarly terminated.

Applications running under the same service group may communicate witheach other via the event manager 4904 by way of a service-group definedprotocol 4950 as seen in FIG. 49. In the protocol 4950, the format andcontents of data packets sent between applications (e.g. 4926 and 4934)should be defined by the authors of those applications that coexistwithin the same service group).

Seen in FIG. 50 is another feature of service groups within thearchitecture 4900, where a service group may contain one or moreapplications that may run as part of any other service group. Theseapplications provide services that may be required across servicegroups. An example of such an application is a personal identificationservice that can provide the postal address and credit card details of auser (once the user has agreed to provide those details). In thisrespect, such a service may form a component of numerous other servicesor transactions that require a financial transaction, these includingon-line shopping and banking.

The design of applications to support the architecture 4900 may or maynot be the same as existing approaches to application design dependingon whether applications developed require the new features provided bythe architecture 4900. Existing applications will still function withsome modification under the architecture 4900. An example of such amodification is where each application that runs under an existingarchitecture can be assumed to have a service group that has the samename as the running application (ie. each application forms its ownservice group having only one member), or some other method of choosinga group name that is unique, including not having a group name forexisting applications or applications that do not work with otherapplications.

Applications within the same service group need not operate on the samephysical hardware, and may not be able to communicate directly with eachother by using operating system defined methods. Two methods ofcommunication are preferably implemented in the event manager 4904 toprovide a standard method of inter-application communication. Thesemethods are:

-   -   (i) a datagram based protocol where a message is sent by one        application to another; and    -   (ii) a protocol based on a message board, where messages are        posted by applications 4920 to a common area from which any        application 4920 in the same service group are able to read the        messages.

The event manager 4904 imposes no structure on the data that is passedbetween applications 4920. All the messages are just blocks of data ofknown length. Any other structure that is imposed on the data only needsto be understood by the applications of the particular service group.The blocks of data may be given types (e.g. raw data, .wav, .doc, etc.)which are stored by the event manager 4904 by the posting application.

A datagram method is used to allow the sending of arbitrary length datafrom one application in a service group to another application in thesame service group, and require that the sending application knows theidentification (ID) number (also referred to above as the Xid) of thereceiving application. The ID number is generated by the correspondinglauncher 4910 when the application 4920 is started to uniquely identifythat application 4920. The ID number is unique only in the context ofthe event manager 4904. In this fashion, many running applications canhave the same ID number but every ID number will be unique amongst allthe applications 4920 that are connected to the same event manager 4904to which the particular application is connected. It is theresponsibility of the corresponding launcher 4910 to ensure that thisoccurs, although the event manager 4904 can detect when duplicate IDnumbers are about to be used and prevent the new application fromstarting.

To send a message using the datagram method, the sending applicationretrieves the Xid of the destination application from the event manager4904 and then sends the message via the event manager 4904 to thedestination application using this Xid to address the message. The eventmanager 4904 does nothing to the packet that contains the message exceptto ensure that the data length and sender fields of the header arecorrect.

For the datagram method to be available, the event manager 4904 mustprovide the applications with some method of determining what otherapplications are running in their service group. This information mustalso include some method for applications to identify what otherapplications are capable of. Such is performed in the architecture 4900using a list of function strings that the application lists when theapplication registers with the event manager 4904. This list offunctions is service specific as the event manager 4904 does not need tounderstand them in any way. Only other applications in the service needto understand what each function string means.

The event manager 4904 may impose some upper limit on the size ofmessages that can be passed using this method.

In the architecture 4900, the message board mentioned above allows datato be broadcast to all applications in the service group at once andalso allows the applications in the service group to store data in acentral repository. This removes the need for any one application to bealways present in a service group. The message board also allows smartcards, and therefore applications in a service group, to be inserted/runin an arbitrary order. Applications post the data they contribute to theservice group onto the message board and when an action needs to betaken by an application, the application can examine the message boardfor the data that is required.

To post data to the message board, the posting application sends to theevent manager 4904 the data desired to be posted, a description string,and in some instances some form of typing information (e.g. a MIMEtype). If the application does not supply the type information, theevent manager 4904 will assign the data a default type (e.g. defaultbinary data, the MIME type application/octet-stream). The event manager4904 then assigns this message a message identifier, which is used toidentify the message in the message board. This message identifier isused to retrieve the message from the message board by otherapplications. The message identifier is also used by the postingapplication to remove the message from the message board. The messageboard, and any messages remaining on the message board corresponding toa service group are destroyed when a service group is terminated.

To retrieve a message from the message board, an application must findthe message identifier of the message that is required. The applicationcan obtain a listing of the messages on the message board, which willcontain the message identifier, poster identifier and the messagedescription of each of the messages on the board. The second methodinvolves also obtaining a listing of running applications from the eventmanager 4904. This provides the application with the functions that eachapplication provides for the service. The application requesting themessage from the message board can then cross-reference the applicationidentifier (Xid) of the application from which it needs the information,against the poster identifier on the message board, and then retrieveall messages posted by that application.

The format of both the messages and the message descriptions on themessage board is decided by the service group and may be totallyarbitrary. The event manager 4904 does not force any structure upon thedata.

To support such a method of communication, the event manager 4904 isrequired to maintain the message board. To the event manager 4904, themessage board appears simply as a list of known length data blocks. Whenan application posts a message to the message board, the event manager4904 stores the data and its length. When an application reads a messagefrom the message board, the event manager 4904 sends the data to theapplication. The event manager 4904 also creates a listing the contentsof the message board for applications that request such a listing.

The event manager 4904 may limit the total size of messages that eachapplication can post as well as the total size of all messages that canbe posted by all applications in a service group, so that eachapplication has a message size limit and each service group has amessage size limit. The number of messages an application and servicegroup may post may also be limited. The size of the descriptions of themessages may also be limited to a maximum length.

13.3 System Initialisation

This section describes the process of initially starting the system 600incorporating the software architecture 4900 of FIG. 48. It is relevantto the computer system 600A as well as a distributed set-top box system600B.

Firstly, the master launcher 4908 is started and listens over thenetwork 220 for a reply over a communication port. The event manager4904 is then started and makes a connection to the master launcher 4908.

This order of starting these two core parts of the architecture 4900 isarbitrary in the case of the system 600A, but has distinct advantageswhen used in a set-top box system 600B. In the system 600B the masterlauncher 4908 is already running when the event manager 4904 is started,it is possible to start more event managers when more users subscribe tothe service, and to reduce the number of running event managers whenusers leave the service.

13.4 System Start-up

This section describes the process of starting a smart card systemincorporating the hardware architecture of FIG. 6A or 6B and thealternative software architecture of FIG. 48. This description assumesthat there is already an event manager 4904 and a master launcherrunning and they have an open connection.

-   -   (i) The I/O daemon 4902 is started and initiates a connection to        the event manager 4904.    -   (ii) The event manager 4904 accepts the connection from the I/O        daemon 4902. It is at this stage that any service accounting can        be performed. For instance if the user hasn't paid the bill then        the connection can be refused.    -   (iii) The event manager 4904 requests a new launcher 4910 from        the master launcher 4908 informing the master launcher 4908 what        port the event manager 4904 is listening on, and then waits for        an incoming connection.    -   (iv) The master launcher 4908 starts a new launcher 4910 and        gives the new launcher 4910 the address and port number of the        event manager 4904.    -   (v) The new launcher 4910 initiates a connection with the event        manager 4904.    -   (vi) The event manager 4904 accepts the connection.

The system 600 is now ready to start applications 4920 as the userinserts smart cards into the reader 1 and initiates a first buttonpress.

13.5 Starting the First Smart Card Service

This section describes the process of starting a smart card service ifno other service is running on the system 600 incorporating the softwarearchitecture of FIG. 48. This is the situation when the system is firstinitiated and can also occur if a service terminates, either though atime-out or because the user touched the remote 1 with no smart card 10inserted.

-   -   (i) The user inserts the smart card 10 into the reader 1 and        presses the touch panel 8.    -   (ii) The pressed event is sent to the event manager 4904 which        reformats the packet and forwards it onto the launcher 4910.    -   (iii) The launcher 4910 receives the packet and recognises that        no service is active and queries the directory service 4912 with        the service identifier (the vendor identifier and the        application identifier) and the service-specific identifier (the        card identifier) of the smart card 10.    -   (iv) The query returns the location of the appropriate        application 4920, which the launcher 4910 then fetches. The        application 4920 will generally be sourced remotely from storage        on a server computer somewhere in the network 220, but may need        to be run locally to the launcher 4910. In advanced systems, the        application may be run remotely from the launcher.    -   (v) The launcher 4910 informs the event manager 4904 that a new        application 4920 is starting.    -   (vi) When the application 4920 has finished downloading to the        launcher where it is to be run, it is started by the launcher        4910.    -   (vii) The application 4920 initiates a connection with the event        manager 4904 and when the event manager 4904 has accepted the        connection, the application 4920 registers with the launcher        4910. This includes what service groups that application 4920 is        part of and what functions the application is capable of        performing.    -   (viii) The launcher 4910 tells the new application 4920 that it        is gaining focus.

The application 4920 at this stage has started and capable of receivingevents. PRESS, RELEASE and MOVE messages generated from the reader 1 areforwarded to the applications 4920 by the event manager 4904 so long asthey are intended from that application. The application 4920 cannotinteract with the event manager 4904 in any way until registered hasbeen completed. Further, the event manager 4904 will not forward eventsto the application and any events that are not application registrationevents that the event manager 4904 receives from an application 4920that has not registered, will be discarded.

13.6 Starting, Controlling and Stopping an Application

FIGS. 56( a) and (b) show a method 5600 of starting, controlling andstopping an application (a application #1-#n) of applications 4920 toprovide a service to a user on the system 600 incorporating the softwarearchitecture 4900. The process of method 5600 is executed by CPU such asCPU 205 in system 600A or CPU 4305 in system 600B. A software programindicating the method 5600 is stored in a memory medium such asCD-ROM212 in system 600A or Memory 4306 in system 600B. When a userinserts the smart card 10 into the reader 1 and presses the touch panel8 to select desired indicia, CPU45 in the reader 1 reads Card Header1100 and data associated with the selected indicia from the smart card10 and sends the pressed event (e.g. Press Message) associated with theselected indicia to the event manager 4904 that reformats the packet.The event manager 4904 sends the pressed packet (e.g. EM-READER PRESS)to Launcher 4910. The software program is executed by the CPU thatexecutes at least Card Interface (Demon) 4902, Event Manager 4904,Launcher 4910 and Applications 4920 in same computing device, when CardInterface (Demon) 4902 receives the pressed event from the reader 1 andsends it to Event Manager 4904. On the other hand, if the softwareprogram is executed by each CPU in a separate computing device, a firstCPU in a first computing device executing Event Manager 4904 executessteps from 5603 to 5608 and second CPU in a second computing deviceexecuting at least Launcher 4910 and applications 4920 executes stepsfrom 5609 to 5636.

At step 5603, by executing Event Manager 4904, the CPU receives thepressed event from the reader 1 via Card Interface 4902 and at the nextstep 5605 the CPU determines if the Service Identifier (the vendoridentifier and application identifier) in the pressed event matches thatof a front application (e.g. application #1) of applications 4920already running. If it is determined that the Service identifier matchesthat of the front application (e.g. application #1) using a matchingtable at the next step 5605, by executing Event Manager 4904 at the nextstep 5608 the CPU forwards the pressed packet to the front applicationand the method 5600 concludes. The table having a relation between eachapplication of applications 4920 and corresponding service identifier isstored in a RAM in Memory 206 or Memory 4306. If it is determined thatthe service identifier does not match that of the front application atthe step 5605, at the next step 5607 the CPU forwards the pressed packetfrom Event Manager 4904 to Launcher 4910. At the next step 5609, byexecuting Launcher the CPU queries the directory server 4912 with theservice identifier and receives location of the new application (e.g.application #2) corresponding to the service identifier. At the nextstep 5611, by executing Launcher 4910, the CPU fetches the newapplication from the location. At the next step 5613, by executingLauncher 4910, the CPU executes the new application (e.g. application#2). At the next step 5615, the CPU initiates a connection between thenew application and Event Manager 4306 and when Event Manager 4306 hasaccepted the connection, the CPU registers the new application withLauncher 4910 and also the application tells the Launcher 4910 whichservice groups it is part of At the next step 5616, the CPU determinesif the new application shares a service group with a currently runningapplication using a service group table stored in a RAM in Memory 206 orMemory 4306. The table having a relation each service identifier andcorresponding service group is stored in the RAM in Memory in Memory 206or Memory 4306. For example, in the table, service identifier 1(application #1) and service identifier 3 (application #3) correspond toa service group A and service identifier 2 (application #2) and serviceidentifier 4 (application #4) correspond to a service group B. At thenext step 5616 if it is determined that the new application shares theservice group with the currently inning application, at the next step5635 by executing Launcher 4910 the CPU tells the current application(the front application) that it is losing focus. At the next step 5636by executing Launcher 4910 the CPU tells the new application that it isgaining focus and the method 5600 concludes. In this case, the CPU isstill executing the current application (the front application) in thebackground but no longer receives any events from the reader 1. Byexecuting the current application the CPU can still send broadcastmessages and messages to specific applications but cannot remove itselffrom service groups.

At the step 5616 if it is determined that the new application does notshare the service group with the currently running application, at step5617 by executing Launcher 4910 the CPU tells the applications that arecurrently running to exit and sets time-out. At the next step 5621 byexecuting Launcher 4910 the CPU waits for time-out then terminates anyremaining applications except the new application. At the next step 5623by executing Launcher 4910 the CPU informs the Event Manager 4904 of theapplications which have exited or been terminated. At the next step 5636by executing Launcher 410 the CPU tells the new application that it isgaining focus and the method 5600 concludes. In this case the CPU is nowexecuting the new application and receives pressed packet such asEM-READER PRESS, EM-READER-RELEASE and EM-READEF MOVE that are intendedfor it. The system 600A or 600B is now running a new service with onlyone application within the service.]

13.7 Passing Data Between Two Applications

This section describes the process of passing data between twoapplications 4920 (application #1) and 4920 (application #2) using thedatagram protocol on the system 600 incorporating the softwarearchitecture of FIG. 48. This method requires that the sendingapplication #1 know the application identifier (Xid) of the receivingapplication #2.

-   -   (i) The sending application #1 gathers the data that it wishes        to send.    -   (ii) The sending application #1 asks the launcher 4910 for the        list of applications that are running in the current service        group.    -   (iii) The launcher 4910 sends the application #1 the list of all        applications in the current service group. This list includes        the functions that each application has told the launcher 4910        that it can perform as well as the descriptive string the        application provided. This list is order with the most recent        application listed first.    -   (iv) The sending application #1 looks to see if there is a        suitable recipient for the data. If there is not, then it is up        to the application #1 to decide how to proceed. The application        #1 could, for example, not bother sending the data, or possibly        ask the user to insert another smart card 10, which will start        the required application.    -   (v) If there is a suitable recipient then the sending        application #1 sends the data to the receiving application #2        via the event manager 4904.    -   (vi) The event manager 4904 checks the message header to ensure        that the sending application #1 has correctly filled out the        data length and sender fields and then passes the message to the        receiving application #2. If there is no such application #2        running, then the event manager 4904 discards the message and        sends an error message back to the sending application #1.        13.8 Posting Data to a Message Board

This section describes the process of posting data to a common messageboard on the system 600 incorporating the software architecture 4900.

-   -   (i) The posting application 4920 gathers the data that it wishes        to post on the message board.    -   (ii) The posting application 4920 sends the data to the event        manager 4904 along with a short description of the data.        13.9 Retrieving Data from a Message Board

This section describes the process of retrieving data that has beenpreviously been posted to the message board by another application onthe system 600 incorporating the software architecture 4900.

-   -   (i) The requesting application #2 asks the event manager 4904        for a list of messages on the message board.    -   (ii) The event manager 4904 sends the application #2 the list of        messages on the message board. This list will contain the short        description of the data, the application identifier (Xid) for        the application 4920 that posted the message to the message        board and the message identifier for all messages on the message        board.    -   (iii) The application #2 can then ask the event manager 4904 for        a particular message by its message identifier, or the        application #2 can request the list of all applications        currently running from the launcher 4910.    -   (iv) If the application #2 has asked for the list of running        applications the launcher 4910 will then send it to the        application #2. This list will contain the application        identifier (Xid) and the list of functions the corresponding        application reported to the launcher 4910 that the corresponding        application can perform.    -   (v) The requesting application #2 can then find all or some        messages from the applications that perform the functions that        it is looking for.        13.10 Removing Data from a Message Board

This section describes the process of removing data that has beenpreviously posted to the message board by the same application, oranother application on the system 600 incorporating the softwarearchitecture 4900.

-   -   (i) The requesting application #2 asks the event manager 4904        for a list of messages on the message board.    -   (ii) The event manager 4904 sends the application #2 the list of        messages on the message board. This list will contain the short        description of the data, the application identifier (Xid) of the        posting application and the message identifier for all messages        on the message board.    -   (iii) The application #2 can then ask the event manager 4904 to        remove a particular message by specifying the specific message        identifier.        13.11 Application Examples

EXAMPLE A Card Orderings

A number of potential application card orderings exist that may beimplemented. The architecture 4900 places no restriction on which cardordering, or combination of card orderings is adopted for an application4920.

Sequential card ordering in an service group, illustrated in FIG. 51A,requires that smart cards 10 for a particular set of applications to beinserted in a specified order. For example, card A followed by card Bfollowed by card C, with removal and/or reinsertion following the sameordering.

Hierarchical card ordering in a service group and requires the cards fora particular set of applications to be inserted in a tree-like fashionas illustrated in FIG. 51B where if card A is inserted, only cards B orC may be then inserted. If card B is removed, card A must be reinserted.If card C is inserted, only card D may be inserted, and if card D isremoved, only card C may be inserted.

A fully-meshed card ordering in a service group permits cards for a setof applications to be inserted and used in any order.

EXAMPLE B Pizza Ordering Service

With a prior art pizza ordering application, a number of choices forpizza type are presented (such as vegetarian, supreme and meat lovers),but no functionality is provided for customisation of the toppings or tomake use of special offers.

An example set of applications that would make up a Joe's Pizzeriaservice group under the architecture 4900 could be as follows:

-   -   (i) Joe's Pizza Menu;    -   (ii) Topping Specialist;    -   (iii) Current Specials; and    -   (iv) Personal identifier.

Each of these applications can be made to work with the otherapplications to create a fully featured pizza ordering service. TheJoe's Pizza Menu application provides a user interface that allows acustomer to select a pizza type (vegetarian, supreme etc.), drinks(cola, lime etc.) and side orders (garlic bread, pasta, etc.). Thisapplication also keeps a shopping-basket style list of the currentorder, and provides buttons on the smart card for resetting the order,and completing the order.

The Topping Specialist application provides a user interface that allowsa customer to move through a list of currently ordered pizzas, and toadd/remove toppings to a selected pizza from a set of toppings printedon the surface of the card. The list of pizzas available is obtainedfrom a running Joe's Pizza Menu application. Changes made to thetoppings of a pizza will propagate back to the Joe's Pizza Menuapplication for modification of the pizza order.

The Current Specials application provides controls to navigate through alist of current special offers available from Joe's Pizzeria Anyspecials selected are communicated to a Joe's Pizza Menu application foraddition to an existing order.

The Personal identifier application provides a method of selectivelycommunicating the home address and home phone number of the user to theJoe's Pizza Menu application depending on the details that a user wishesto supply.

EXAMPLE C Photo Lab Service

In prior art Photo Album and T-Shirt applications, a clipboard is shared(as a file) for communication of currently selected photographs. Thereis no facility however, for modification of a photograph (for examplecropping, or increasing the brightness), or to have a number of linkedcards that represent a full roll of film, with each card currently onlycontaining a maximum of 20 photographs, each photograph beingrepresented by an icon large enough to act as a button.

With the architecture 4900, a Photo Lab service may be designed thatwould have the following set of cards:

-   -   (i) Film_1 a,    -   (ii) Film_1 b;    -   (iii) T-Shirt printer, and    -   (iv) Photo Enhancer.

The Film_1 a and Film_1 b cards represent a complete roll of Advantix(trade mark of Kodak Corp. of USA) film containing 40 photographs each,and may be inserted with either card first. Once either card isinserted, access is provided to the complete set of photographs spanningboth cards with direct access to photos that are printed on the surfaceof the inserted card. This means that a slideshow function would cyclethrough the photographs corresponding to both cards. Each card wouldalso have buttons for adding a particular photograph reference to theservice group clipboard for user with another application in the PhotoLab service group, and the application would also provide a functionreturning a reference to the photograph currently being viewed.

The T-Shirt printer application provides the ability to either instantlyprint a T-Shirt transfer using the most recently viewed photograph (areference to which is obtained from the Film application), or to composea T-Shirt transfer from the set of photos residing on the clipboard.

As part of a simple photo editing service, the Photo Enhancerapplication operates on the most recently viewed photograph (obtainedeither from the T-Shirt application, or the Film application—whicheverwas most recently in the foreground). The Photo Enhancer may providesuch operations as automatic crop, sharpen, blur, lighten darken etc.,with the changes able to be pushed back to the photo server and madepermanent.

EXAMPLE D Video Email Service

Prior art video email applications provide a means to send video emailmessages to video email users appearing on the surface of the card. Withsome re-design it is possible to create a Video Email service accordingto the architecture 4900 in which an address book can be compiled ofusers that supply their smart card business cards to the owner of theaddress book. Applications forming the Video Email service are:

-   -   (i) Video Email Send;    -   (ii) Video Email Mailbox;    -   (iii) Video Email Address Book; and    -   (iv) Business Card.

The Video Email Send application operates in much the same way as theprior art application, with the exception that an address may beobtained from an inserted personal identification card, or an insertedBusiness Card.

The Video Email Mailbox application provides functions for retrievingvideo email messages from a remote server, and can also provide theaddress of senders for use as a reply address with the Video Email Sendapplication

Address book functionality is provided by the Video Email Address Bookapplication. This application allows a user to build up a list ofaddresses from different Business Cards, personal identifier cards, orVideo Email Mailbox cards that have been inserted. One or more entriesfrom the list of addresses may be selected for use with a Video EmailSend application.

EXAMPLE E Shopping Basket Service

With conventional software architectures, applications that providedonline shopping needed to each maintain their own purchasing system,including a shopping basket, ordering, billing, and shipping means. Ashopping basket service designed to make use of the features availableas part of the architecture 4900 would allow these functions to be splitout of each online shopping application, leaving more user interfacearea for other functions. Applications that would form part of such aShopping Basket Service are:

-   -   (i) E-Deliver Shopping Basket;    -   (ii) Davy Jones Online; and    -   (iii) Pace Bros. Online.

The E-Deliver Shopping Basket application provides an overall shoppingbasket management facility, payment, and ordering facilities.

Davy Jones Online, and Pace Bros. Online applications provide facilitiesfor browsing through a list of available items for purchase, withassociated item descriptions, from corresponding department stores. Whenan item is found that a user wants to purchase, the item can be added tothe shopping basket for future ordering and delivery by way of theE-Deliver Shopping Basket application.

It will be appreciated from the forgoing, that the architecture 4900 maybe used to implement a card interface system that affords expandedflexibility through sectionalising management processes and through thejudicious launching of applications. This has permitted applications tobe operated co-operatively to achieve a functional result. Further, suchenables the various components of the architecture 4900 to be operatedfrom hardware platforms of varying complexity through the capacity tooperate procedures on platforms commensurate with their complexity. Suchplatforms range from low end set-top boxes with limited processingpower, to home PC's, and remote server computers. Specifically, with a“dumb” set-top box, the card daemon 4902 would be run from within theset-top box and the balance of all processes from one or more remoteserver computers. Conversely, with a smart set-top box or home-stylepersonal computer, all processes may be operated from within the onepiece of hardware, excepting for where external communications via thenetwork 220 is essential.

The architecture 4900 is also extensible to support security modelsappropriate to a particular application in order to protect both usersand vendors from unauthorised data siphoning and fraud.

By virtue of the event manager 4904 acting as a conduit of eventcommands, the architecture is able to operate with applicationsdeveloped over a range of versions of the communication protocol, assuch would typically be developed over the course of time.

The architecture 4900 allows the card interface system 600 to continueto function even when card applications are not complying with expectedmodes of operation. This includes applications unexpectedly exiting,refusing to exit on command, and sending incorrect or excessive data tothe system 600. The architecture 4900 supports multi-card applicationsby virtue of each card in the application belonging to the same servicegroup, thereby ensuring that the application is maintained running whena card is removed and a new card inserted.

13.12 Application Management System

The architecture 4900 has been described above utilising the concept ofservice groups, their establishment, and their extinction, in order topermit multiple applications to operate simultaneously withoutoverloading computing resources and ensuring adequate response.

An alternative approach in considering multiple applications arises frominterpreting data flow between applications as being from producers ofdata to consumers of data. FIG. 55 shows a directed graph, with thegraph direction flowing from consumers to producers for performing acollective function, in this case a T-shirt having a name and aphotograph transferred to its surface, that data being derived from anumber of other applications. The management of applications within sucha graph structure depends upon the accessibility of nodes of the graph.Specifically, when a node becomes unreachable in the graph, theapplication at that node should be terminated, since, at that stage,that application is unable to perform a cognisant function. Further,links to a node should be removed when a consumer of that application'sproduct de-registers for that service. When an application starts, theapplication is placed in the tree. If the application is a producer of atype that a consumer wants, the application is placed under that node inthe tree.

As described above, the applications 4920 are referenced by theircorresponding vendor identifier and application identifier whichtogether are equivalent to the service identifier described above forthe architecture 200. The application identifier (or Xid) is used as aunique key for quick matching when starting-up an already runningapplication. There are two application identifiers, the one stored onthe card with the vendor identifier and the card identifier (A cardidentifier is equivalent to the service-specific identifier describedabove with reference to the architecture 200), and one assigned by thesystem to applications when they start (the latter applicationidentifier being referred to herein also as the component identifier orXid, the former application identifier being related to the serviceidentifier as described above).

Each application may register, using its Xid for identification, as aproducer or consumer of a functionality on a needs basis. Theapplication knows what it needs at a certain point in time by way ofuser interaction. For example, the user may navigate through theapplication to an “add photo” screen, at which point the application mayregister as a photo consumer. Registration in this regard is preferablybe on the basis of a functionality, rather than a service group, as aservice group approach would be too general for practical purposes.Further, such wouldn't allow an application to be linked to another in aconsumer/producer relationship when the producer may not be able toprovide the specific service that the producer requires unless all theapplications in a service group support all functionality's offered bythat service group.

Such a model presents two options for implementation, since anapplication may require two or more functions from any otherapplications:

-   1. Each node in the graph has only one connection to any other node.    This means that the connection must also contain a list of the    service included in the consumer/producer relationship. Each time a    consumer de-registers for a service the list entry is removed. When    the list of services for a connection becomes empty, the connection    is removed. When a connection is removed, any producer that is    linked by that connection is also checked. If the producer node is    no longer connection to any other, that node may be removed.-   2. This option is similar to (1) above except that instead of    keeping a list of services, each specific service is a separate    connection between the consumer/producer node. Thus, there may be    multiple connections between two applications. When a consumer    de-registers for a service, that connection is removed. If the    producer is no longer connected, the consumer is terminated.

Such proposals are problematic in that each allows the applicationassociated with the smart card presently in the reader 1 to beterminated by an event other than a specific user action. This may beconfusing from the user point of view. An alternative approach totermination of an application is therefore desired.

In such an alternative approach, the architecture 4900 may be operatedwithout specific dependence upon any application 4920 being a member ofa specific service group as described above, but through the transientformation of what is referred to herein as a “dominant” service group. Adominant service group arises from any transient functional relationshipbetween two or more current applications being determined from whetherany application 4920 is classed as either a producer, a consumer, both aproducer and consumer, or neither a producer nor a consumer.

Such a management system for the applications 4920 revolves around theconcept of the “dominant” service group being formed when aproducer/consumer pair of applications, or a single application wherethat application meet both criteria, in the same service group areregistered. For example simultaneous operation of applications Ac and Apwill cause service group A to be dominant and satisfies aproducer-consumer pair, whereas AcBp or ApBc whilst satisfying aproducer-consumer pair, will not create a dominant service group.According to the management system, when a dominant service group isformed, all applications not sharing that group are terminated. Thedominant service group may exist in conjunction with a second dominantservice group, provide both are registered simultaneously. For example,if Application#1 starts and registers ApBp and Application#2 starts andregisters AcBc, A and B are then dominant For two or more dominantservice groups to exist, they must be formed when a new applicationstarting registers for each group establishing a producer-consumer pair.A producer/consumer pair of applications forming a service groupregistered after a dominant service group becomes a “subsidiary” of thedominant group. A subsidiary group of a subsidiary group may also beformed. A subsidiary of a subsidiary is formed when a producer of thesubsidiary that was already registered as a consumer for the secondsubsidiary.

The net effect of such a management structure is the creation, andsubsequent dismantling, of a tree or graph of interacting applicationsthat pass data there between to achieve a final result desired by theuser. Specifically, such a result may not be readily apparent from onthe face of the applications being utilised, in contrast to Example Babove for the pizza ordering service. This application managementstructure is best described with reference to the examples below.

The examples below make reference to a number of applications, detailsof which are described in Table 4 below.

TABLE 4 Card Service Group Member Application (p = producer, c = NameDescription consumer, n = neither) ID1 Identification detail card Zp CpID2 Identification detail card Zp Qp PhotoID photograph identificationcard Zp Qp Ap Photo1 photograph card Ap Fp Photo2 photograph card Mp ApPIN personal identification Pp number card Bank electronic banking cardBn Pizza pizza ordering card Rn T-shirt T-shirt manufacture Tp CardMakercard used for making Sp other cards

EXAMPLE F

In this example, it is desired by the user to create a greeting cardhaving the recipient's name, a standard message, and a photograph on thecard. A first step using the cards of Table 4 would be for the user toinsert the CardMaker application card into the reader 1. Such an actioncommences that application and registers that application as a consumerof service groups A and Z. Applications may dynamically change theirservice group membership. For example, CardMaker may start and presentthe user with a screen display asking if the user wants to make a cardidentical to the card created on a previous occasion. Upon answering“NO”, CardMaker registers as a consumer for ID1 and Photo1 since a newcard will be made. A process tree for this stage appears as shown inFIG. 53A. Next, the user knows that a photograph is required, andprovides that photograph by removing the CardMaker application and byinserting the Photo1 application. The CardMaker application remains inoperation upon removal from the reader 1 since, its processes have yetto perform a function. The insertion of Photo1 application crates adominant service group in Ac and Ap as illustrated, meaning that theCardMaker application requires a photograph and the Photo1 applicationcan supply that photograph. The Photo1 application, requires a PIN toaccess the photograph and the arrangement is thus as represented in FIG.53B. Not all photographs on the Photo1 card may require a PIN to unlockthem for use, so Photo1 only registers as Pc when it requires a PIN toproceed, such as in the present case. The PIN card is then providedaccording to FIG. 53C. As seen from FIG. 53C, a second producer-consumerpair is formed, and in this case the provision of the PIN, allows thePhoto1 card to supply the photograph selected by the user to theCardMaker application. Those tasks having been completed, the leftbranch of the process tree is extinguished and those corresponding“performed” applications de-register from the event manger 4904, asshown in FIG. 53D. The next step to complete the process is to insert acard having the desired name, which in this case comes from theapplication ID1 as shown in FIG. 53E. This application supplies therequired name and the CardMaker application is thus satisfied, therebypermitting all other applications to de-register and terminate. TheCardMaker application can then output the required card withoutinteraction with any other application.

In an alternative approach, the PIN application may be required toaccess both the photograph and the name. As such, the PIN applicationcard need only be inserted the once only if the PIN for both photo cardsis the same, and a process tree such as that shown in FIG. 54 may beformed. In this example PhotoID and Photo1 are used since PhotoID mayhave a picture of the recipient of the card being made, and Photo1 mayhave an attractive background picture to place over the photo.

FIG. 54 demonstrates that multiple links to nodes in the process treeare permitted, and that applications on unreachable nodes (being thosewith no links) are terminated.

Preferably, an upper limit on running applications is set to be seven(7). If this number is exceeded, termination of applications commenceswith the oldest leaf application in the process tree.

The foregoing describes only some arrangements and variations on thosearrangements of the present invention, and modifications and/or changescan be made thereto without departing from the scope and spirit of theinvention, the embodiments being illustrative and not restrictive.

1. A service providing apparatus for providing a service to a user of auser interface card, said card being configured for insertion into areceptacle of a card read device, and said card comprising a substratewith indicia formed thereon, said apparatus comprising: a centralprocessing unit for receiving, from said card read device, first dataidentifying one of said indicia, said first data being read from amemory of said interface card, and for receiving second data identifyingsaid interface card, wherein said second data is transmitted to saidservice providing apparatus multiple times between an insertion and asubsequent removal of said interface card from said receptacle of saidcard read device, said service providing apparatus being configured forproviding said service based on said first data and said second data. 2.A service providing apparatus according to claim 1, wherein said firstdata is information data defining a user pressed position on asubstantially transparent touch sensitive membrane of card read device,said membrane being arranged to overlay said interface card, saidinformation data being received from the card read device upon a userpressing said touch sensitive membrane when the card is not insertedinto the read device.
 3. A service providing apparatus according toclaim 1, wherein said central processing unit is configured to control achange from a current front application to one of a plurality of furtherapplications upon said second data being different from data associatedwith the front application.
 4. A service providing apparatus accordingto claim 1, wherein said central processing unit alerts a user upon aninvalid card being inserted into said card read device.
 5. A serviceproviding apparatus according to claim 1, wherein said centralprocessing unit is configured to utilize a memory address defined by thefirst data to access data that was stored at said memory address.
 6. Aservice providing apparatus according to claim 5, wherein said memoryaddress is a URL.
 7. A service providing apparatus according to claim 1,wherein said second data is transmitted to said service providingapparatus upon selection of said one indicia.
 8. A service providingapparatus according to claim 1, wherein said second data is transmittedto said service providing apparatus upon selection of said one indiciabeing released.
 9. A service providing apparatus according to claim 1,wherein said second data is transmitted to said service providingapparatus upon said interface card being inserted into said card readdevice.
 10. A service providing apparatus according to claim 1, whereinsaid second data is transmitted to said service providing apparatus uponsaid interface card being removed from said card read device.
 11. Aservice providing apparatus according to claim 1, wherein said seconddata is transmitted to said service providing apparatus upon a positionof selection of said indicia moving.
 12. A service providing apparatusaccording to claim 1, wherein said second data is a service identifier.13. A service providing apparatus according to claim 12, said serviceidentifier is set by a vendor for use by an application.
 14. A serviceproviding apparatus according to claim 13, wherein said serviceidentifier is assigned to said vendor by a central authority.
 15. Aservice providing apparatus according to claim 1, wherein said seconddata is a pseudo-random number.
 16. A service providing apparatusaccording to claim 1, wherein said second data is incremented each timesaid card is inserted into said receptacle.
 17. A service providingapparatus according to claim 1, wherein said second data is stored insaid memory of said interface card.
 18. A service providing apparatusaccording to claim 1, wherein said service providing apparatus is aset-top box.
 19. A service providing apparatus according to claim 1,wherein said service providing apparatus is a personal computer.
 20. Aservice providing apparatus for providing a service to a user of aninterface card, said card being configured for insertion into areceptacle of a card read device, and said card comprising a substratewith indicia formed thereon, said apparatus comprising: means forreceiving from the card read device first data identifying one of saidindicia, said first data being read from a memory of the card; and meansfor receiving from the card read device second data identifying saidinterface card, wherein said second data is transmitted by said cardread device to said service providing apparatus multiple times betweenan insertion and a subsequent removal of said interface card from saidreceptacle of said card read device, said service providing apparatusbeing configured for providing said service based on said first data andsaid second data.
 21. A method of providing a service to a user of aninterface card, said card being configured for insertion into areceptacle of a card read device, and said card comprising a substratewith indicia formed thereon, said method comprising the steps of:receiving from the card read device first data identifying one of saidindicia, said first data being read from a memory of said cardreceiving, from the card read device, second data identifying saidinterface card, wherein said second data is transmitted by said cardread device to said service providing apparatus multiple times betweenan insertion and a subsequent removal of said interface card from saidreceptacle of said card read device; and providing said service based onsaid first data and said second data.
 22. A computer readable storagemedium having a computer program recorded thereon, the program to beexecuted by a service providing apparatus for providing a service to auser of an interface card, said card being configured for insertion intoa receptacle of a card read device, and said card comprising a substratewith indicia formed thereon, said program comprising: code for receivingfrom the card read device first data identifying one of said indicia,said first data being read from a memory of said card code forreceiving, from the card read device, second data identifying saidinterface card, wherein said second data is transmitted by said cardread device to said service providing apparatus multiple times betweenan insertion and a subsequent removal of said interface card from saidreceptacle of said card read device; and code for providing said servicebased on said first data and said second data.
 23. A computer readablestorage medium according to claim 22, wherein the program is stored on acomputer-readable medium in said service providing apparatus.